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ABSTRACT 


Efficient  processing  of  views  is  critical  to  many  real 
world  applications,  particularly  real  time  applications  such 
as  surveillance  systems  which  support  military  applications. 
This  thesis  compares  the  performance  of  three  view 
materialization  strategies:  semi-materialization,  full 
materialization  and  query  modification.  This  thesis  first 
develops  a  program  that  generates  databases  according  to  user 
specification.  Second  the  generated  databases  are  used  to 
conduct  an  empirical  study  on  the  three  view  materialization 
strategies  using  select-project- join  and  general  expression 
views.  The  results  of  the  study  indicate  that  for  select- 
project-join  view  definitions,  semi -materialization  performed 
best  for  higher  values  of  P,  lower  values  of  1,  fv  and  all 
values  of  fq  with  the  database  stored  on  hard  disk.  Full 
materialization  performed  best  for  lower  values  of  P,  2,  and 
all  values  of  fv  with  the  database  stored  in  RAM.  The  results 
also  indicate  that  the  semi-materialization  strategy  is  the 
best  view  processing  method  for  general  expressions. 
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I .  INTRODUCTION 


A.  BACKGROUND 

A  database  is  a  computer  based  record  keeping  system  that 
contains  information  used  uo  support  an  organization's 
tactical  ( short  range )  and  strategic  ( long  range )  goals .  For 
example,  a  database  for  a  sales  organization  could  contain 
customer,  employee,  sales  and  inventory  data. 

Several  data  models  are  available  to  organize  the 
information  within  the  database  so  that  it  can  be  utilized  in 
an  efficient  manner.  One  of  the  most  common  data  models  is  the 
relational  model.  This  method  organizes  data  in  terms  of 
tables  ( relations ) ,  rows  ( tuples )  and  columns  ( attributes ) . 

Tables  can  be  classified  as  either  base  tables  or  views. 
A  base  table  is  a  table  that  physically  exists  in  its  own 
right.  A  view  maybe  thought  of  as  a  virtual  table,  in  as  much, 
that  it  does  not  (normally)  exist  within  its  own  right  but  is 
instead  derived  from  one  or  more  underlying  base  tables 
[Ref.  1].  The  view  is  stored  as  a  definition  in  the  data 
dictionary  and  is  combined  with  a  user’s  query  to  retrieve  the 
requested  data  from  the  base  tables. 
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The  use  cf  views  allows  for  the  structuring  and  limiting  of 
the  information  retrieved  by  a  given  query.  This  feature 
allows  the  user  to  receive  data  that  is  relevant  to  the 
application  and  limits  unauthorized  user  access  to  other 
critical  data. 

Recently  several  proposals  have  considered  storing  some 
form  of  the  processed  view  to  eliminate  the  need  to  evaluate 
the  view  definition  from  scratch  every  time  it  is  queried.  The 
first  approach,  known  as  full  materialization,  stores  the 
fully  processed  view  as  a  physical  table.  This  approach  has 
the  advantage  of  increasing  the  efficiency  of  the  queries  on 
the  view  ,  but  incurs  an  additional  expense  of  maintaining  the 
materialized  view.  To  overcome  this  problem,  a  second 
approach,  called  semi-materialization,  was  proposed  whereby  a 
partially  processed  rather  than  a  fully  materialized  view  is 
stored.  This  approach  redundantly  stores  data  that  represents 
selections  and  projections  of  individual  relations,  thus 
allowing  efficient  evaluation  of  the  view  definition  while 
being  easy  to  maintain. 

View  performance  processing  is  directly  related  to  the 
performance  of  real  time  applications  such  as  surveillance 
systems  which  support  military  operations.  These  systems 
receive  periodic  environmental  updates  from  various  sensors 
which  are  used  to  evaluate  a  view.  Any  delay  processing  the 
sensor  data,  which  is  typically  time  sensitive,  into  usable 
information  could  render  the  information  late  and  unusable. 
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Faster  view  processing  used  in  conjunction  with  real  time 
systems  will  significantly  improve  the  response  time  of  these 
systems . 

B.  OBJECTIVE 

The  objective  of  this  thesis  is  to  compare  empirically  the 
performance  of  three  view  processing  strategies:  query 
modification,  semi-materialization  and  full  materialization. 
The  research  attempts  to  verify  the  analytical  results  which 
have  indicated  that,  in  general,  the  semi -materialization 
strategy  is  the  best  method  for  processing  general  expression 
views  [Ref.  2].  To  accomplish  this  goal,  this  research 
develops  a  Data  Generation  Program  to  produce  test  databases 
according  to  user  specifications.  The  test  databases  are  then 
used  to  compare  the  performance  of  three  view  processing 
strategies  for  two  view  expressions  and  under  different 
parameter  settings,  using  a  simulation  program  that  was 
developed  by  Lt  Jesse  South  [Ref.  3].  Performance 
results  were  then  collected,  analyzed  and  plotted  for 
presentation  in  this  thesis. 
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C.  SCOPE  AND  METHODOLOGY 

This  thesis  accomplishes  the  following: 

1 .  Develops  a  generic  database  generating  program  using 
ANSI  C  to  generate  test  databases  according  to  user 
spec i f icat ions . 

2.  Compares  the  performance  of  three  view  materialization 
strategies  for  select-project-join  expressions  with  the 
database  stored  in  Random  Access  Memory  (RAM)  and  hard 
disk. 

3.  Tests  the  three  view  strategies  using  general 
expressions  with  the  database  stored  on  RAM  and  on 

hard  disk  under  different  parameter  settings,  collecting 
the  results  and  comparing  them  with  analytical  results. 

4.  Uses  the  results  to  draw  conclusions  and  determine  the 
conditions  under  which  each  strategy  performs  the  best. 

D.  ORGANIZATION  OF  STUDY 

This  thesis  is  organized  as  follows.  Chapter  11  overviews 
the  three  view  processing  strategies.  Chapter  III  provides  a 
detailed  description  of  the  Data  Generation  Program.  Chapter 

IV  presents  the  performance  results  of  the  empirical  study  and 
compares  them  to  the  results  of  the  analytical  study.  Chapter 

V  presents  conclusions  based  on  the  study  and  suggests  areas 
for  future  research. 
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II.  VIEW  MATERIALIZATION  STRATEGIES 


The  purpose  of  this  chapter  is  to  provide  a  general 
overview  of  the  three  view  materialization  strategies  -  query 
modification,  semi-materialization  and  full 
materialization. 

A.  QUERY  MODIFICATION 

The  conventional  method  for  view  processing  for  queries  is 
query  modification.  This  method  stores  a  view  definition  in 
the  data  dictionary.  This  view  definition  is  retrieved  from 
the  data  dictionary  when  a  query  is  issued  on  the  view  and 
combined  with  the  user  query  into  an  equivalent  query  on  the 
underlying  base  tables.  This  query  is  subsequently  processed, 
and  the  results  returned  to  its  user.  Consider  the  following 
database  schema: 

EMP(  E# , ENAME , ADDRESS , SALARY, TITLE ) 

POS(E#,S#, LEVEL) 

and  the  corresponding  view  definition  COMBATSTAFF: 

Ue.ESOM.B.  ENAME,  e.  SALARY 
{op.  LEVEL>Z  {EMP^POS) ) 


Now  when  a  query  is  issued  against  COMBATSTAFF: 

nc.SNUM,  C.  ENAME {oC.3ALARY>Z0, 000  {COMBATSTAFF)  ) 
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The  view  mechanism  translates  the  query  into  the  equivalent 
query  on  the  base  relations: 

Ub.ENUM,b.ENAME 

(ae.salary>Z0,00Q^p.LEVEL>3  (EMP*^POS) ) 

The  resulting  query  is  optimized  to  determine  the  best  access 
path  and  then  executed. 

B.  FULL  MATERIALIZATION 

This  method  creates  an  actual  table  based  on  the  view 
definition.  The  resulting  table  is  used  to  perform  user 
queries,  thus  avoiding  the  cost  of  repeatedly  retrieving  a 
view  definition  and  creating  equivalent  queries  on  the  base 
relations.  This  method  works  quite  well  for  processing 
queries,  but  is  costly  when  the  frequency  of  update  is  high, 
since  the  full  materialized  view  must  be  maintained. 

Updates  are  defined  as  a  transaction  which  performs  a 
sequence  of  tuple  insertions,  tuple  deletions,  and  tuple 
modifications  on  a  relatlon(s).  Suppose  that  a  set  of  tuples 
A  is  added  to  a  relation  and  a  set  of  tuples  D  is  deleted  from 
the  same  relation.  The  tuple  sets  A  and  D  represent  the  net 
change  made  to  that  relation.  In  that  case,  a  tuple  which  is 
Inserted  and  deleted  in  the  same  transaction  would  not  appear 
in  either  tuple  set  A  or  D. 


Using  this  method,  the  net  results  of  an  update 
transaction  could  be  used  as  a  basis  for  a  differential 
algorithm  to  update  the  materialized  view. 

In  fact  this  method  works  quite  well  using  select-project- 
join  expressions  because  selections  and  projections  can  be 
performed  over  unions.  Using  the  view  definition  in  the 
previous  section  and  limiting  the  updates  to  the  POS  relation 
for  simplicity,  the  view  expression  becomes: 

COMBATSTAFF^»(X)blBATSTAFF'lle .  ENUM,  e .  ENAME,  e .  SALARY 
(p.  LBVBL>3  (D^»-«P05) ) 

mie .  ENUM.  e .  EtIAMB.  e .  SALARY {p .  LEVEL>  3  (A^xPOS)  ) 

The  above  expression  shows  that  the  fully  materialized  view 
can  be  maintained  by  computing  the  last  two  expressions  and 
inserting  them  into  or  deleting  them  from  the  materialized 
view  COMBATSTAFF. 

Unfortunately  a  similar  expression  can  not  be  derived  if 
a  general  expression  is  used  in  the  view  definition.  At 
present  no  efficient  differential  algorithm  exists  for 
performing  Incremental  updates  for  general  expressions.  This 
fact  necessitates  that  a  complete  re-evaluation  of  the  view 
expression  be  accomplished  after  each  update  to  the  base 
relations.  The  cost  of  re-evaluating  a  fully  materialized  view 
can  be  prohibitive  as  the  frequency  of  updates  for  the  base 
relations  Increase,  which  is  the  chief  problem  associated  with 
this  method. 
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C.  SEMI -MATERIALIZATION 

This  method  stores  redundant  subsets  of  carefully  chosen 
data  from  individual  base  tables.  These  redundant  subsets  are 
stored  as  actual  tables  and  represent  an  Intermediate  state  of 
computing  the  view.  Each  subset  is  a  projection  and  selection 
of  the  base  table(s)  thus  making  the  construction  of  the  view 
less  costly  than  using  the  base  relations. 

The  redundant  data  is  clustered  on  the  join  attribute(s) 
which  allows  for  the  efficient  construction  of  the  view. 
Updates  to  the  base  relations  are  screened  to  determine  if  the 
update  affects  the  redundant  tables.  If  it  does,  it  is 
inserted  into  or  deleted  from  the  appropriate  redundant 
tables . 

The  following  redundant  subsets  would  be  stored  to  support 
this  technique: 

e.ENAME,  e.  SALARYiEMP) 
POS'»Up.ENUM{ap.LEVEL>Z  {POS) ) 

This  view  is  combined  with  a  user  query  to  form  an  equivalent 
query  on  the  redundant  relations: 

He.  ENUM,  C.  ENAME,  C.  SALARY{EMP'*<POS') 
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When  queried  the  following  equivalent  view  is  created  using 
the  redundant  tables  and  the  view  definition: 

Ue'.ENUM,  e'.ENAMEie*.SALARY>20,000  (EMP'*<POS')  ) 

This  method  becomes  more  complicated  as  additional 
insertions  and  deletions  occur.  Since  more  than  one  base 
relation  may  have  been  the  source  of  the  tuples  used  in  the 
materialized  view,  it  becomes  increasing  difficult  to 
determine,  when  or  if  a  record  should  be  removed  from  the 
view. 

To  alleviate  this  problem  each  materialized  view  must  keep 
a  duplicate  count  of  the  number  of  tuples  contributed,  by  each 
redundant  subset,  to  the  tuples  in  the  materialized  view  when 
the  subsets  are  Joined.  The  count  should  be  incremented  or 
decremented  depending  on  the  transaction  until  the  count 
becomes  zero. 
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III.  DATA  GENERATION  PROGRAM 


The  purpose  of  this  chapter  is  to  describe  the  Data 
Generation  program.  According  to  user  specifications  the 
program  generates  text  files  that  are  used  subsequently  to 
build  the  test  database.  As  shown  in  Figure  1,  the  program 
reads  control  information  from  a  text  file  created  by  a  user 
or  generated  by  the  simulation  program  and  generates  the 
specified  text  files.  The  program  allows  the  user  to  control 
the  number  of  records  (cardinality  of  the  relation),  the  data 
type  (ALPHA,  NUMERIC  or  ALPHANUMERIC  characters),  the  size  of 
each  field  and  the  number  of  fields  generated  for  each  record. 


Figure  1:  Data  generation  program  data  flow 
overview. 
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The  process  to  generate  the  data  is  hidden  from  the  user 
by  using  a  fixed  format  control  file  as  the  user  interface  to 
the  program. 

The  program  is  written  in  ANSI  C  to  increase  portability 
of  the  source  code  and  to  minimize  the  changes  necessary  to 
transfer  the  program  to  a  mini  or  mainframe  environment.  The 
maximum  size  of  the  text  file  generated  by  the  program  is 
limited  only  by  the  secondary  storage  available  on  the 
platform  in  use. 

A.  GENERAL  DESCRIPTION 

The  Data  Generation  program  receives  control  data  from  the 
text  file  "DATA_IN" .  The  information  in  the  control  data  file 
is  effectively  divided  into  two  sections.  The  first  section 
determines  the  nvunber  of  records,  fields  per  record  and  the 
name  of  the  output  file.  The  second  section  defines  each  field 
within  the  record  by  type  of  information  for  the  field  (Field 
Type: Alpha,  Numeric  or  Alphanumeric):  the  number  of  characters 
for  each  attribute  (Field  Width):  the  upper  and  lower  bounds 
for  any  arrays  and  the  Incremental  value  used  for  counters. 
Data  Generation  program  reads  the  data  into  a  set  of  linked 
lists  which  are  passed  to  the  control  modules  by  the  main 
module  to  create  each  record. 
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B.  REQUIREMENTS 


The  requirement  for  the  Data  Generation  program  was  based 
on  a  user  request  that  a  new  generic  data  generating  program 
be  written  in  the  C  programming  language  to  replace  the 
previous  database  generating  program. 


Figure  2:  Data  generation  program  parameters  and  parameter 
definitions. 


A.  RECORD  STRUCTURE 


1.  NUMBER  OF 
RECORDS 

2.  NUMBER  OF 
FIELDS 

3. TDCrRl£ 
NAME 


B.  FIELD  STRUCTURE 

1.REIJ)TYPE 

A:  ALPHA 

N:  NUMERIC 

0;  ALPHA¬ 
NUMERIC 

4.  ARRAY 
LOWER 
BOUND 

2.  FELD  WIDTH 

5.  INCREMENT 

3.  FELD  INFO 

S:  SEQUENTIAL 
B:  ARRAY 
a- RANDOM 

D;  DEFAULT 

6.  ARRAY 
UPPER 
BOUND 
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The  program  accepts  the  following  inputs  and  generates  a 
text  file  used  to  create  test  databases: 

1.  Number  of  text  files  required. 

2.  Number  of  records  per  text  file. 

3.  Name  of  the  text  file. 

4.  Number  of  fields  per  record. 

5.  Size  of  each  field. 

6.  Type  of  information  in  each  field. 

7.  Number  of  distinct  values  in  each  field. 

8.  Upper  and  lower  limits  for  the  fields. 

9 .  Input  reference  for  randomly  generated  characters . 

To  simplify  the  performance  analysis  several 
assumptions  were  made  about  the  data  generated  for  the  test 
database.  The  first  assumption  was  that  the  values  for  each 
field  in  the  column  were  uniformly  distributed  over  the  range 
of  values  in  the  column.  The  second  assumption  considered  each 
value  in  a  given  column  to  be  independent  of  the  values  in  the 
other  columns. 

C.  NOTES  ON  PROGRAM  DESIGN 

The  requirement  for  maximum  program  flexibility  dictated 
a  "layered”  design  approach  be  used,  creating  Individual 
primitive  modules  to  produce  the  varied  types  of  output  data 
requested  by  the  user. 
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To  keep  the  coupling  between  the  modules  as  loose  as 
possible,  the  use  of  global  variables  is  minimized  and  when 
feasible,  only  a  single  record  structure  is  passed  between 
the  called  and  calling  modules. 


Figure  3:  Data  generation  program  control  module 
overview. 


Each  primitive  module  prints  Its  output  directly  to  the 
output  text  file  with  the  exception  of  the 
generate_numerlc_array  module  which  returns  its  numeric  output 
to  the  random_generator  module  for  conversion  to  alpha 
characters,  if  required. 


This  method  was  chosen  after  trial  and  error  as  the  best 
method  for  facilitating  the  tracing  of  data  and  control  flow 
through  the  modules. 

The  rand(  )  C  library  function  was  used  to  generate  random 
data.  Two  C  language  record  structures  were  used  to  establish 
the  command  language  between  the  data  generation  program,  the 
control  file  and  the  view  materialization  simulation  program. 

D.  PROGRAM  MODULE  OVERVIEW 

A  brief  description  of  each  module  is  provided  to  clarify 
the  control  and  data  flows  that  are  described  in  Section  E. 

1 .  Main  Module 

The  main  module  opens  and  closes  the  input-output 
files,  loads  the  control  data  into  the  record  structures  and 
directs  the  flow  of  the  control  data  to  the  applicable  modules 
for  data  generation. 

2.  Tlae  Hack  Module 

The  time  hack  module  uses  the  systei  clock  to  compute 
the  base  reference  for  the  generation  of  random  alpha  and 
numeric  output  values. 

3 .  Typ«_Muaeric  Module 

The  typo_nuroeric  module  is  called  by  the  main  module 
to  generate  a  ntunerlc  string,  or  call  the  sequential  counter, 
random_generator  or  the  bounded_sequentlal_array  modules. 


15 


4 .  Type__Alpha  Module 

The  type_alpha  module  is  one  of  three  process  control 
modules  used  to  determine  the  type  of  characters  in  a  field. 
The  module  receives  its  input  in  the  form  of  a  record 
structure  passed  from  the  main  module  to  generate  a  string  of 
?lpha  characters,  or  to  call  the  random_generator  or  the 
bounded_sequential_array  modules . 

5 .  Type_Alphanumerlc  Module 

The  type_alphanumeric  module  is  the  last  process 
control  module  and  generates  a  single  variaole  length  string 
of  alpha  and  numeric  characters  when  called  by  the  main 
module . 

6 .  Bounded_Sequentlal_Array  Module 

The  bounded_sequential_array  module,  which  is  called 
by  either  the  type_alpha  or  type_numeric  modules,  receives 
three  numeric  values  from  the  calling  module.  The  values 
determine  the  array  lower  bound,  the  number  of  array  elements 
and  the  incremental  value  of  each  element.  The  rand(  )  function 
is  used  to  generate  a  random  index  number  to  select  the  array 
element  value  that  is  printed  in  the  output  file. 


7 .  Random_Generator  Module 

The  random_generator  module  is  called  in  the  same 
manner  as  the  bounded_sequential_array  module.  The  module 
determines  if  a  character  or  numeric  value  is  required,  calls 
the  generate_numeric_array  module  to  produce  the  required 
value  and  prints  the  value  or  character  in  the  output  file. 

8 .  Random__Long_Array  Module 

The  random_long_array  module  is  called  by  the 
type_numerlc  module  to  produce  a  random  numeric  output 
employing  the  same  rand(  )  function  that  was  used  in  the 
bounded_sequential_array  module.  The  module  computes  the  array 
size  and  determines  if  the  number  of  array  elements  exceeds  a 
preset  limit. 

The  module  will  compute  the  output  value  using  the 
upper  bound  value  and  the  rand( )  function  to  conserve  main 
memory  rather  than  allocating  space  for  the  array  if  the 
preset  limit  is  exceeded.  This  method  was  used  to  prevent  the 
program  from  using  memory  unnecessarily. 

9 .  Counter  Module 

The  counter  module  is  called  by  the  type_numeric 
module  and  uses  global  values  to  generate  up  to  three 
independent  sequential  counters. 
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10.  Generate_Numerlc_Array  Module 

The  genera te_nunjeric_arr ay  module  is  called  by  the 
randoin_generator  module  to  produce  a  second  independent 
bounded  array  similar  to  the  bounded_sequential_array  module 
except  the  random  numeric  output  from  the  module  is  returned 
to  the  calling  module  for  possible  conversion  to  an  alpha 
character , 

11 .  Print  Modules 

The  print  modules  are  all  used  to  send  debugging  data 
to  a  text  file  called  "output.txt"  that  is  controlled  by  a 
toggle  called  "TROUBLESHOOTING". 

E.  DETAILED  DATA  AND  CONTROL  FLOW 

The  Data  Generation  Program  is  called  by  a  batch  file 
which  reads  the  control  file  "DATA_IN" .  The  input  data  is 
formatted  to  conform  to  the  two  record  structures  declared  in 
the  definition  section  of  the  program. 

Once  the  input  data  is  loaded  into  the  program,  the 
control  file  is  closed  and  the  output  file  is  opened.  The 
output  file  name  is  part  of  the  control  file  data.  Each  record 
structure  is  read  and  control  is  routed  to  the  appropriate 
control  module  based  on  field  type  (  ALPHA  "A",  NUMERIC  "N" 
and  ALPHANUMERIC  "0"). 
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The  type_numeric  module  will  be  used  to  trace  the  first 
data  flow  through  the  modules,  the  second  data  flow  be  traced 
using  the  type_alpha  module  and  the  last  data  flow  will  use 
type_alphanumeric  module. 

"N"  is  the  field  type  read  by  the  main  module  in  the 
attribute  record  structure.  Control  and  the  attribute  record 
structure  is  passed  to  the  type_numeric  module  by  the  main 
module.  The  attribute  record  structure  is  read  by  the  module 
to  determine  the  field  information  (BOUNDED  SEQUENTIAL  ARRAY 
"B",  RANDOM  GENERATOR  "R",  COUNTER  "S",  RANDOM  LONG  ARRAY  "X" 
or  DEFAULT  "D"). 

The  field  information  type  read  by  the  module  is  "B"  and 
the  bounded_sequential_array  module  is  called.  The 
type_numerlc  module  converts  the  lower  and  upper  bound 
character  strings  to  numeric  values  which  are  passed  to  the 
bounded_sequentlal_array  module  along  with  the  incremental 
data.  The  module  uses  the  input  data  to  determine  array  size, 
the  lower  bound  and  Increment. 

Memory  is  allocated  and  the  array  is  filled.  The  rand( ) 
function  and  the  array  size  are  used  to  compute  an  random 
index  number  to  select  the  array  element  value  to  be  printed 
in  the  applicable  field  in  the  output  field. 
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Control  is  returned  to  the  main  module  and  the  next 
attribute  record  structure  is  read.  "A"  is  the  next  field  type 
read  by  the  main  module:  control  and  the  attribute  record 
structure  is  passed  to  the  type_ alpha  module. 

The  type_alpha  module  reads  the  attribute  record 
structure.  ”R"  is  the  field  information  read  by  the  module. 
The  randomgenerator  module  is  called,  the  lower  bound 
character  and  upper  bound  character  strings  are  read  by  the 
type_alpha  module.  The  character  strings  are  converted  to 
numeric  values  and  passed  along  with  the  incremental  data  to 
the  random_generator  module. 

The  random_generator  module  determines  if  the  integer 
values  represent  alpha  characters  or  numeric  values.  In  this 
case,  the  values  represent  the  upper  case  letters  "A" (lower 
bound),  "R"  (upper  bound),  and  the  increment  value  of  1.  The 
random_generator  computes  the  array  size,  and  passes  the 
values  to  the  generate_numeric_array  module  to  generate  the 
array . 

The  generate_numerlc_array  module  allocates  and  fills  the 
array.  The  rand( )  function  is  used  to  select  an  array  value 
which  is  returned  to  the  random_generator  module.  The  value  is 
converted  to  an  alpha  character  in  the  random_generator  module 
and  printed  in  the  applicable  field  in  the  output  file. 
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Control  is  returned  to  the  main  module  and  the  next 
attribute  record  is  read.  "O"  is  the  next  field  type  read  by 
the  main  module;  control  and  the  attribute  record  structure  is 
passed  to  the  type_alphanumeric  module. 

Unlike  the  other  control  modules  the  type_alphanumeric 
module  does  not  call  other  modules.  The  attribute  record 
structure  is  read  to  determine  the  total  number  of  alpha  and 
numeric  characters  required.  Total  field  width  is  the 
aggregate  of  the  two  character  strings. 

The  characters  are  generated  sequentially  "A  -  Z"  for  the 
alpha  string  and  "0  -  9"  for  the  numeric  string.  The 
characters  are  printed  to  the  output  file  one  at  a  time  until 
the  field  is  completed. 

The  process  for  the  other  field  Information  types  is 
similar  for  both  the  type_alpha  and  type_numeric  modules. 
ERROR  handling  is  limited  to  verification  of  the  input  data 
and  the  opening  of  the  required  input  and  output  files. 

F.  TESTING 

Testing  was  conducted  on  each  module  when  it  was  created 
or  updated.  Small  text  files  which  simulated  the  input  data 
for  the  particular  module  being  tested  was  modified  to  test 
each  module  over  a  wide  range  of  values.  The  entire  program 
was  tested  using  a  variety  of  control  files  to  create  text 
files  from  50  to  over  60,000  records  with  at  least  10 
attribute  fields  per  record. 


21 


IV.  PERFORMANCE  ANALYSIS 


The  purpose  of  this  chapter  Is  to  describe  and  report  the 
results  of  the  empirical  study  conducted  on  the  three  view 
materialization  strategies  —  query  modification,  full 
materialization  and  semi-materialization  —  using  select- 
project-  Join  (Model  1)  and  general  expressions  (Model  2). 
Performance  testing  was  conducted  on  databases  stored  in 
Random  Access  Memory  (RAM)  and  on  a  hard  disk  using  a  computer 
with  an  INTEL  80386SX  processor  running  at  20  MHz.  The 
simulation  program  is  written  in  ANSI  C  with  embedded  SQL 
commands  to  access  the  INGRES  relational  database  system. 

A.  SUMMARY  OF  THE  RESULTS  FOR  THE  ANALYTICAL  MODEL 

Review  of  the  results  for  the  analytical  model  indicate 
that  view  processing  strategies  are  most  sensitive  to  the 
frequency  of  updates  (P),  the  selectivity  of  the  view 
predicate  ( f v ) ,  the  selectivity  of  the  query  predicate  ( f q ) 
and  number  of  tuples  (1)  [Ref.  2].  For  select-project- Join 
expressions,  and  except  for  high  values  of  P,  both  full  and 
semi -materialization  performed  better  than  query  modification. 
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Higher  values  of  P,  fv,l  or  lower  values  of  fq  favor  semi¬ 
materialization  over  full  materialization.  At  lower  values  of 
P,  fv,  and  1  full  materialization  is  slightly  better  than 
semi-materialization  as  the  update  costs  tend  to  be  low. 

For  general  expressions  semi-materialization  performed 
better  for  all  parameter  values  except  for  very  low  values  of 
P.  The  absence  of  an  efficient  differential  algorithm  for 
performing  incremental  updates  makes  the  use  of  general 
expression  an  unattractive  alternative. 

B.  EXPERIMENTAL  SETUP 

The  parameter  definitions,  parameter  default  values, 
access  paths  for  the  relations,  query  and  view  definitions  and 
the  profiles  of  the  database  relations  which  were  used  for 
the  experiment  are  shown  in  Figures  4  through  8,  respectively. 
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Figure  4:  View  materialization  parameter 

definitions. 
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Figure  6:  Access  paths  for  relations. 


The  parameters  that  were  considered  for  the  sensitivity 
analysis  Include  the  following  for  each  model  tested: 

1 .  The  fraction  of  updates  to  the  total  number  of 
operations  (P).  This  parameter  is  controlled  by  varying  the 
number  of  update  transactions  on  the  base  relations  {k)  and 
the  number  of  times  the  view  is  queried  ( g ) . 
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2.  The  selectivity  of  the  view  predicate  (fv)  or  the 
fraction  of  tuples  retrieved  in  the  view  with  regard  to  the 
control  relation  POS.  This  fraction  is  controlled  by  varying 
the  value  v_threshold  (view_cut)  -  that  is,  the  predicates  in 
the  view  definition. 

3.  The  selectivity  of  the  query  predicate  (fq)  or  the 
fraction  of  tuples  retrieved  by  the  query  on  the  view.  The 
fraction  (fq)  is  controlled  by  varying  the  value  q_threshold 
( query _cut)  -  that  is,  the  predicate  in  the  query. 

4.  The  number  of  tuples  modified  by  each  transaction  (I). 
This  parameter  is  controlled  by  varying  the  number  of  tuples 
per  update  generated  by  the  data  generation  program. 

5.  The  number  of  records  in  the  base  relatlon(s) 
(cardinality  of  the  relation). 

Performance  data  was  collected  for  view  definitions  using 
select-project-join  and  general  expression  predicates  with  the 
database  stored  in  RAM  and  on  hard  disk. 

The  database  and  the  data  generation  program,  view 
materialization  simulation  program  and  various  Ingres  program 
files  were  placed  in  separate  sub-directories  on  the  hard  disk 
or  in  two  similar  RAM  drives  (4MB  for  database  and  1.8MB  for 
the  other  files)  to  determine  if  eliminating  the  hard  disk 
access  time  (28ms  average)  would  significantly  improve  the 
performance  of  the  view  processing  strategies. 
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EXPRESSION 


VIEW  1: 

CREATE  VIEW  FULk.VIEW 

SELECT  E_NUM.  ENAME.  SALARY,  KEYNO 
WHERE  a.EJNUM  -  p.E_NUM  AND 
p-LEVEL  >-VIEWCUT 

VIEW  a: 

CREATE  VIEW  FULU.VIEW 

SELECT  E_NUM.  ENAME,  SALARY,  KEYNO 
WHERE  EXISTS 
(SELECT  * 

WHERE  •f.NUM  -  p.E-NUM 
p_eJaEVNO  -pJ.KEYNO 

ANDp_I.LeVEL  >-VIEWCUT) 

QUERY 

SELECT  E_NUM.  ENAME,  KEYNO 

WHERE  SALARY  >•  QUERYCUT 

VIWMI:  V»VK 


Flgiire  7:  View  definitions  and  query  on  the  views. 


Two  types  of  operations  were  conducted  on  the  test 
database,  a  series  of  update  transactions  on  the  base 
relations  which  modified  a  varying  number  of  tuples  per  update 
and  queries  Issued  against  views. 
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Figure  8:  Profile  of  database  relations. 
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The  average  elapsed  time  per  query  for  all  updates  and 
queries  is  used  to  compute  the  performance  of  each  strategy. 

C.  PERFORMANCE  ANALYSIS 

This  section  discusses  the  performance  of  the  three  view 
processing  strategies  for  view  definitions  which  used  select- 
project-  join  and  general  expression  predicates.  These 
strategies  were  applied  to  the  test  database(s)  produced  using 
the  EMP,  POS  and  SKILL  text  files  generated  by  the  data 
generation  program.  The  reporting  method  will  consist  of 
reviewing  the  results  for  each  parameter  used  in  the 
sensitivity  analysis  of  the  two  models. 

1.  Model  1  :  Select-Project- Join 

MODEL  1  uses  the  following  view  definition  with  a 
select-project-join  predicate  for  the  three  view  processing 
strategies : 

He .  ENUM,  e .  EtfAME,  e .  SALARYip .  LEVEL^vievcut  {EMP^POS)  ) 

a.  Results  for  Database  In  RAM 

In  this  section,  the  results  of  the  sensitivity 
analysis  for  Model  1  for  the  database  in  RAM  is  presented. 
Figures  9  through  12  show  the  results  for  model  1  for  the  four 
different  parameter  values  when  using  the  ram  disk. 

In  general,  the  trends  computed  for  the  analytical 
model  were  supported  by  the  empirical  results  for  the  runs 
with  the  database  stored  in  RAM. 
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The  sensitivity  analysis  for  the  probability  of 
update  parameter  shows  semi-materialization  performs  best  for 
values  of  P  greater  than  0.5  with  the  database  in  RAM. 

Full  materialization  was  the  clear  winner  for  values  of  P  less 
than  0.5. 

This  tradeoff  occurs  because  for  values  greater 
than  0.5  the  cost  of  processing  queries  for  full 
materialization  averages  .35  seconds  while  the  cost  to  perform 
updates  averaged  .7  seconds.  The  cost  per  query  for  semi- 
materlalization  averaged  .8  seconds  but  the  cost  for  updates 
averaged  to  only  .2  seconds. 

As  the  number  of  updates  Increased  the  update  cost 
for  semi -materialization  was  quartered  while  the  cost  for  full 
materialization  doubled. 

The  average  cost  for  query  modification  was  4.3 
second  per  transaction.  Query  modification  exhibited  the  same 
trend  as  the  analytical  model. 
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Figure  9:  Total  cost  per  query  In  seconds  vs.  the 
ratio  of  updates  to  the  total  number  of  operations 
P. 


For  the  selectivity  of  view  parameter,  the 
performance  of  the  full  and  semi-materialization  strategies 
were  virtually  Identical  for  values  of  fv  less  than  0.3.  The 
performance  of  semi-materialization  Improved  over  the 
performance  of  full  materialization  as  the  value  of  fv 
Increased . 

The  average  cost  per  update  was  .78  seconds  and 
cost  per  query  was  .63  seconds  for  full  materialization  for 
values  of  fv  less  than  0.3.  As  expected,  the  cost  for 
performing  updates  Increased  significantly  as  the  value  of  fv 
Increased . 
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selectivity  of  the  view  predicate  fv. 


The  average  cost  of  updates  for  semi- 
materlalizatlon  was  .76  seconds  while  the  cost  for  queries 
averaged  3.26  seconds  over  the  entire  range  of  values  for  fv. 

The  cost  for  query  modification  Increased  as  the 
size  of  the  view  Increased  over  the  range  of  fv  as  expected. 
The  empirical  results  for  query  modification  were  virtually 
identical  to  the  analytical  model  trends. 

Full  materialization  provided  the  best  performance 
for  all  values  of  fq  for  the  strategies  with  the  database  in 
RAM. 


30 


The  average  cost  per  update  for  full 
materialization  was  .7  seconds  while  the  cost  per  query 
averaged  2.2  seconds. 


Flgiire  11:  Total  cost  per  query  in  seconds  vs.  the 
selectivity  of  the  query  on  the  view  fq. 


The  average  cost  per  update  for  seml- 
materlallzatlon  was  .25  seconds  but  the  cost  per  query 
averaged  3.7  seconds.  Seml-materlallzatlon  conformed  to  the 
trends  indicated  in  the  analytical  results  for  fq. 

The  average  cost  per  transaction  for  query 
modification  was  6.2  seconds  which  conformed  to  the 
performance  noted  for  the  analytical  model. 


There  was  very  little  difference  between  the 
performances  of  semi-  or  full  materialization  over  the  entire 
range  of  values  of  i  -  number  of  tuples  per  update  for  the 
database  in  RAM. 

Full  materialization  performed  slightly  better  for 
values  of  1  less  than  40.  Semi-materialization  performed  best 
for  values  of  1  from  50  to  80  and  greater  than  90. 

The  average  cost  per  update  for  semi- 
materiallzation  was  .32  seconds  while  the  average  cost  per 
query  was  . 79  seconds  for  all  values  of  I .  The  average  cost 
per  query  for  full  materialization  was  .36  seconds  and  average 
cost  per  update  was  .  87  seconds  over  the  same  range  of  1 
values. 


Figure  12:  Total  cost  per  query  in  seconds  vs.  the 
number  of  tuples  modified  by  each  update  1. 
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Full  materialization's  performance  for  the  1  parameter  far 
exceeded  the  expectations  indicated  by  the  analytical  model . 
Query  modification's  performance  on  the  analytical  model 
indicated  a  slight  improvement  for  higher  values  of  I  which 
was  not  supported  by  the  empirical  data. 

h.  Results  for  Datel>ase  on  Bard  Disk 

In  this  section  the  results  of  the  sensitivity 
analysis  for  Model  1  on  hard  disk  are  presented  for  comparison 
to  the  results  for  the  three  strategies  with  the  database  in 
RAM. 

For  the  probability  of  update  parameter,  the 
transition  to  semi -materialization ' s  performance  exceeding 
full  materialization  occurs  at  0.34.  This  indicates,  as 
expected,  that  disk  access  time  when  added  to  the  cost  of 
performing  updates  has  an  significant  impact  on  the 
performance  of  full  materialization. 

Semi-materialization  provides  the  best  performance 
for  values  of  P  greater  than  0.34.  The  figure  shows  a  less 
steep  Increase  for  values  of  P  greater  than  0.7  than  the 
results  with  the  database  in  RAM.  Note,  however  that  the 
processing  cost  in  RAM  is  less  than  50%  of  the  similar  cost  on 
the  hard  disk. 


33 


^  QuMy  ModHeattan 
□  Sami  MatofWbatlon 
o  Ful  MmritUzadon 


iToSoJoSoSojoj  as  a*  i 

fMtoari^dgM(PS)  _ j 

Figur^ 13:  Total  cost  per  query  in  seconds  vs.  the 
ratio  of  updates  to  the  total  number  of  operations 
P. 

For  the  selectivity  on  the  view  parameter,  semi- 
materialization  performed  best  for  all  values  of  fv.  The 
difference  in  the  performance  appears  to  be  due  to  the 
additional  cost  added  for  accessing  the  disk  to  update  the 
base  relation  plus  the  additional  disk  accesses  required  to 
update  the  view. 

In  general  the  trends  are  identical  to  the  trends 
exhibited  by  the  analytical  and  RAM  models. 
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selectivity  of  the  view  predicate  fv. 


Seml-materlallzatlon  was  the  best  performer  for 
values  of  fq  that  were  less  than  0.4.  Full  materialization 
performance  was  better  for  values  greater  than  0.4.  The 
performance  for  both  seml>  and  full  materialization  was 
virtually  identical  for  values  of  fq  between  0.2  and  0.4. 

The  trends  for  the  three  strategies  conform  to  the 
results  shown  for  the  analytical  model. 


35 


Figure  IS:  Total  cost  per  query  In  seconds  vs.  the 
selectivity  of  the  query  on  the  view  fq. 


Semi-materialization  was  the  clear  winner  for  all 
values  of  1.  Full  materialization  's  performance  improved  for 
values  of  1  greater  than  80  but  did  not  out  perform  semi- 
materialization.  Query  modification's  performance  conformed  to 
both  the  analytical  and  RAM  models.  The  results  for  both 
semi-  and  full  materialization  exceeded  the  results  shown  for 
the  analytical  model. 


36 


number  of  tuples  modified  by  each  update  I. 

c.  Dlscmssion  of  the  results  for  Model  1 

In  general  the  empirical  data  supported  the 
conclusions  presented  In  the  analytical  review  of  the  view 
materialization  strategies  [Ref.  4]. 

Seml-materlallzatlon' s  performance  was  superior 
for  higher  values  of  P,  lower  values  of  1,  fv  and  all  values 
of  fq  for  the  database  on  the  hard  dlsk.^  Semi- 
materialization  performed  best  with  the  database  in  RAM  for 
values  of  P  greater  than  0.5,  fv  greater  than  0.3  and  for  I 
values  between  50  to  80  and  greater  than  90. 

^  Seml-materlallzatlon  was  outperformed  by  full 
materialization  for  only  the  first  value  of  fv  while  using  the 
RAM  disk  drive. 
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This  was  due  to  the  low  cost  per  update  for  semi- 
materialization  when  compared  to  the  other  strategies.  The 
cost  advantages  of  performing  queries  and  updates  on  the 
redundant  subsets  is  due  primarily  to  the  fact  that  any 
transactions  performed  using  semi-materialization  are  on 
smaller  table(s)  than  the  base  relations. 

Full  materialization  performed  best  for  lower 
values  of  P,  1  and  for  all  values  of  fq  for  the  database  on 
RAM.  As  expected  full  materialization  performed  best  when  the 
primary  transaction  was  a  query.  Surprisingly,  full 
materialization  overall  performance  on  RAM  was  quite  good  even 
for  the  parameters  for  which  it  was  not  the  best  performer. 
For  example,  in  Figure  12,  full  materialization's  performance 
was  nearly  identical  to  semi -materialization  over  the  entire 
range  of  values  for  1.  Similarly,  full  materialization's 
performance  was  not  significantly  worst  than  semi- 
materialization  for  values  of  fv  as  shown  in  Figure  10.  Full 
materialization  performed  best  with  the  database  on  hard  disk 
for  P  less  than  0.34  and  for  fq  values  greater  than  0.4. 

Query  modification  outperformed  full 
materialization  for  values  of  P  greater  than  0.82  for  RAM  and 
0.84  on  the  hard  disk.  This  was  due  to  the  very  high  cost  per 
update  for  full  materialization  as  discussed  previously. 
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2.  Model  2  :  General  Expressions 

MODEL  2  uses  the  following  general  expression  view 
definition  expressed  in  relational  calculus: 

e .  ENVM,  0 .  ENAME,  0 .  SALARywh0r^ 

(e.  ENUM^p.EtiUMf^.  LEVELS viewcut  (EMP>^POS) ) 

a.  Results  for  Database  In  Mif 

The  results  for  the  database  in  RAM  are  displayed 
in  Figures  17  through  20.  The  trends  exhibited  here  are 
noteworthy  since  the  performances  for  all  the  strategies 
exceed  the  results  obtained  from  the  earlier  experimental  data 
but  tended  to  conform  to  the  analytical  model  [Ref.  4]. 

The  results  for  the  probability  of  updates 
parameter  are  displayed  in  Figure  17  and  Indicate  semi¬ 
materialization  outperformed  query  modification  for  all  values 
of  P.  It  also  outperformed  full  materialization  for  values  of 
P  greater  than  0.1. 
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ratio  of  updates  to  the  total  number  of  operations 
P. 


Seml-materlallzatlon's  average  cost  per  update  was 
0.22  seconds  while  Its  cost  per  query  averaged  5.73  seconds 
over  the  entire  range  of  P  values.  Full  materialization 
averaged  a  cost  per  query  of  0.31  seconds  but  Its  advantage 
was  offset  with  an  Initial  update  cost  of  62.89  seconds.  Query 
modification's  cost  per  transaction  was  33.65  seconds. 

Seml-materlallzatioii  was  the  best  performer  for 
all  values  of  fv,  which  coincided  with  the  trend  for  the 
analytical  model.  The  simulation  results  for  query 
modification  and  full  materialization  were  better  than  the 
results  for  analytical  model  for  all  values  of  fv. 
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The  analytical  and  empirical  results  for  query 
modification  were  nearly  identical  for  the  entire  range  of  fq 
values.  Full  materialization  proved  to  be  the  worst  performer 
of  the  strategies,  as  displayed  in  Figure  19. 

Semi-materialization  cost  per  update  for  fq 
averaged  to  0.23  seconds  while  its  average  cost  per  query  was 
20.7  seconds.  The  average  cost  per  update  for  full 
materialization  was  63.5  seconds  and  its  cost  per  query  was 
1.3  seconds.  Query  modification’s  cost  per  transaction  was 
46.1  seconds. 


Figure  19:  Total  cost  per  query  in  seconds  vs.  the 
selectivity  of  the  query  on  the  view  fq. 
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Figure  20  shows  that  serai-materialization 
outperformed  full  materialization  and  query  modification  for 


all  values  of  I. 


number  of  tuples  modified  by  each  update  1. 

Semi-materialization's  average  cost  per  update  was 
0.28  seconds  and  its  cost  per  query  was  5.7  seconds  for  all 
values  of  1.  Full  materialization's  cost  averaged  to  0.32 
seconds  per  query  and  63.2  seconds  per  update.  Query 
modification's  transaction  cost  averaged  33.7  seconds. 
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The  slight  increase  in  performance  cost  over  the 
entire  range  of  1  anticipated  by  the  analytical  model  for 
semi-materialization  as  the  number  of  tuples  per  update 
increased  was  not  supported  by  the  simulation  results. 

Query  modification  and  full  materialization  conformed  to  the 
results  plotted  for  the  analytical  model  [Ref.  4]. 
b.  Results  for  Database  on  Sard  Di^ 

In  this  section  the  results  of  the  sensitivity 
analysis  for  Model  2  on  hard  disk  are  presented.  Figures  21 
through  28  show  the  results  for  model  2  for  the  five  different 
parameter  values  when  using  the  hard  disk. 

Unlike  the  experiment  conducted  in  RAM  for  the 
three  view  processing  strategies,  the  cardinality  of  the  POS 
relation  will  be  varied  from  7500  to  10,000.  The  methodology 
used  to  conducting  the  sensitivity  analysis  for  the  four  other 
parameter  values  (P,  fv,  fq  and  I)  was  exactly  the  same  as  the 
methodology  used  for  the  experiment  conducted  in  RAM. 
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The  results  for  the  probability  of  updates 


parameter  is  displayed  in  Figures  21  and  22  shows  that  semi- 
materialization  out  performed  query  modification  over  the 
entire  range  of  P  values.  Its  performance  was  better  than  full 
materialization  for  values  of  P  greater  than  0.1. 


ratio  of  updates  to  the  total  number  of  operations 
P  for  7500  records. 


ratio  of  updates  to  the  total  number  of  operations 
P  for  10,000  records. 


The  reason  for  semi-materialization  performance  is 
its  low  cost  per  update  which  offset  its  average  cost  per 
query.  For  an  cardinality  of  7500  records,  semi- 
materialization' s  average  cost  per  update  was  1.55  seconds  and 
19.82  seconds  per  query.  Its  average  per  update  for  an  10,000 
record  cardinality  was  3.41  seconds  with  a  cost  per  query  of 
21.21  seconds. 

Full  materialization  performed  best  for  a  P  value 
of  0.1  or  less  for  both  cardinality  values  but  the  extremely 
high  cost  of  its  first  update  (250  seconds  for  7500:  417 
seconds  for  10,000)  quickly  overcame  its  cost  advantage  for 
processing  queries. 

Query  modification  outperformed  full 
materialization  for  P  greater  than  0.2  because  of  full 
materialization  high  cost  per  update. 

Seml-materlallzatlon  outperformed  both  query 
modification  and  full  materialization  over  the  entire  range  of 
fv  values.  The  cost  per  update  for  seml-materlallzatlon  with 
a  cardinality  of  7500  was  3.7  seconds  and  its  cost  per  query 
was  51.2  seconds  for  all  values  of  fv.  Semi-materialization' s 
cost  per  update  for  a  cardinality  of  10,000  records  was  7.1 
seconds  while  its  cost  per  query  was  59.0  seconds.  Query 
modification  cost  per  transaction  averaged  102  seconds  for 
7500  records  and  180  seconds  for  10,000  records. 
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Full  materialization  cost  per  update  increased  at  a  rate  of 
150%  for  7500  records  and  doubled  for  10,000  records  as  the 
size  of  the  view  increased. 


selectivity  of  the  view  predicate  fv  on  7500 
records . 
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As  shown  in  Figures  25  and  26, 


semi- 


materialization  outperformed  query  modification  and  full 
materialization  for  all  values  of  fq. 

The  average  cost  per  update  for  semi- 
materialization  with  a  cardinality  of  7500  was  1.5  seconds  and 
its  cost  per  query  was  64.5  seconds. 

Semi-materialization's  averaged  costs  for  a 
cardinality  of  10,000  was  2.8  seconds  for  updates  and  73.0 
seconds  for  queries. 


selectivity  of  the  query  in  seconds  on  the  view  fq 
for  7500  records. 


Figure  26:  Total  cost  per  query  in  seconds  vs.  the 
selectivity  of  the  query  on  the  view  fq  for  10,000 
records . 


The  averaged  costs  for  full  materialization  for 
7500  records  was  2.5  seconds  per  query  and  256  seconds  per 
update. Query  modification's  costs  averaged  116.0  ijiconds  for 
7500  records  and  150.6  for  10,000  records. 
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As  expected  semi-materialization  was  the  clear 
winner  over  both  query  modification  and  full  materialization 
over  the  entire  range  of  1  values. 


Figure  27:  Total  cost  per  query  in  seconds  vs.  the 
number  of  tuples  modified  by  each  update  1  for  7500 
records . 


000  records. 
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Semi-materialization's  performance  cost  averaged 
2.1  seconds  per  update  and  18.8  seconds  per  query  with  a 
cardinality  of  7500  for  all  values  of  I. 

Similarly  its  averaged  costs  for  10,000  records 
were  3.7  seconds  per  update  and  20.2  seconds  per  query.  Full 
materialization's  costs  averaged  0.71  per  query  and  253 
seconds  per  update  with  a  cardinality  of  7500.  Its  average 
costs  were  0.72  seconds  per  query  and  421  seconds  per  update 
for  10,000  records.  Query  modification  had  an  average  cost  of 
68.7  seconds  per  transaction  for  7500  records  and  103.2 
seconds  for  10,000  records. 

The  additional  cost  associated  with  using  a  hard 
disk  drive  and  increasing  the  cardinality  had  an  impact  on  the 
performance  experienced  for  both  query  modification  and  full 
materialization. 

The  cost  for  processing  queries  using  query 
modification  on  the  hard  disk  increased  three  fold  over  the 
cost  of  processing  the  query  in  RAM. 

The  cost  of  processing  updates  using  full 
materialization  increased  by  700%  over  the  same  cost  for 
updates  in  RAM  but  the  cost  for  query  processing  only  doubled. 
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The  costs  for  semi-materialization  also  increased 
by  a  factor  of  ten  for  updates  and  quadrupled  for  query 
processing.  The  increase  in  processing  costs  for  semi¬ 
materialization  was  offset  by  the  use  of  the  redundant  subsets 
of  the  base  relation  which  allowed  for  a  more  efficient 
construction  of  the  materialized  view. 

c.  Discussion  of  Results  for  Model  2 

Semi-materialization  performed  better  with  the 
database  in  RAM  and  on  hard  disk  for  the  entire  range  of 
values  of  cardinality  than  both  query  modification  and  full 
materialization  for  all  parameters  except  for  a  value  of  P 
less  than  0.1.  Full  materialization  performed  better  for  P 
less  than  0.1  because  its  average  cost  per  query  was  only  .42 
seconds  while  semi-materialization's  cost  averaged  15.4 
seconds . 

For  values  of  P  greater  than  0.1  the  cost  for 
performing  a  single  update  for  full  materialization  rose  to 
62.89  seconds  for  5000  records  in  RAM,  250  seconds  for  7500 
recoros  on  hard  disk, and  417  seconds  for  10,000  records  on 
hard  disk  which  offset  any  advantage  offered  by  full 
materialization  superior  performance  for  query  processing. 
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This  dramatic  cost  increase  for  update  processing  for  full 
materialization  using  general  expression  predicates  is  due  the 
lack  of  an  efficient  differential  update  algorithm.  This 
necessities  the  complete  re-evaluation  of  the  view  definition 
for  any  update  transaction. 

Query  modification  outperformed  full 
materialization  for  all  parameters  except  for  values  of  P  less 
than  0.35  for  all  values  of  cardinality.  As  indicated  above 
the  cost  of  a  single  update  transaction  for  full 
materialization  quickly  drives  its  cost  higher  than  an  other 
strategies . 

In  this  case  as  the  number  of  updates  Increased 
the  aggregate  cost  for  query  modification  dropped  since  the 
cost  of  updating  base  relations  to  support  this  strategy  are 
not  timed.  The  cost  of  processing  four  or  less  updates 
(average  cost  per  update  for  query  modification  is  0)  combined 
aggregate  cost  for  processing  six  queries  (average  cost  per 
query  is  33.6  seconds)  is  more  than  the  cost  for  processing 
the  same  number  of  transactions  for  full  materialization. 

Full  materialization's  superior  performance  for 
lower  values  of  P  is  evident  and  is  based  its  low  cost  for 
processing  queries  on  the  view.  This  advantage  was  quickly 
overwhelmed  by  the  overhead  of  maintaining  the  fully 
materialized  view  [Ref.  4]. 


Semi-materialization  performed  best  on  hard  disk 
for  all  parameters  expect  for  a  value  of  P  of  0.1  or  less. 
Full  materialization  was  the  best  performer  for  that  value  of 
P  because  the  only  transaction  performed  for  those  values  was 
query  processing. 

As  indicated  above,  semi-materialization  is  the 
best  strategy  for  processing  view  definitions  using  general 
expressions  for  predicates. 

It  is  interesting  to  note  that  the  results  shown 
in  Figures  17  through  28  show  that,  in  general,  the 
performance  trends  for  the  view  processing  strategies  are  the 
same  for  P,  fv,  fq,  and  1  for  the  entire  range  of  values  for 
cardinality  of  POS. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  purpose  of  this  chapter  is  to  state  conclusions  based 
on  the  research  and  make  recommendations  for  improvements  and 
further  study  on  the  three  view  materialization  strategies. 

A.  CONCLUSIONS 

The  empirical  data  of  this  thesis  confirms  that  the  semi- 
materiallzatlon  strategy  is  best  method  for  processing  views 
with  predicates  using  general  expressions. 

The  performance  of  seml-materlallzatlon  with  the  database 
in  RAM  exceeded  the  trends  forecasted  for  general  expressions 
for  the  analytical  model  or  actual  results  achieved  on  the 
earlier  experimental  study  [Ref.  ?].  This  is  reasonable 
because  of  the  cost  penalty  paid  by  the  strategy  when  it 
becomes  necessary  to  access  a  hard  disk  to  perform  updates  and 
queries . 

The  trends  for  the  simulations  for  semi -materialization 
with  its  database  stored  in  RAM  Indicate  it  may  be  suitable 
for  near  real  time  view  processing  using  general  expressions 
based  on  its  relatively  low  average  costs  for  updates  and 
queries . 
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Full  materialization  performed  well  for  lower  values  of  P 
due  to  its  low  average  cost  per  query  while  query 
modification's  performance  was  good  over  all  parameter  values 
but  both  strategies  are  less  efficient  than  semi- 
materialization  for  general  expressions. 

Select-project-join  view  definitions  with  the  database  in 
RAM  proved  to  be  the  most  cost  effective  method  for  view 
processing  (see  Figures  9-12). 

Overall  performance  for  all  parameter  simulations  using 
this  view  definition  and  the  ram  disk  drive  were  three  to  five 
times  faster  than  similar  runs  using  a  hard  disk  drive.  These 
savings  are  significant  when  considering  view  processing  for 
the  small  databases  Inherent  to  tactical  environments. 

B.  RECOMMENDATIONS  AND  FUTURE  RESEARCH 

We  recommend  that  the  same  simulations  for  select-project- 
join  and  general  expressions  be  conducted  with  an  80486 
processor  with  a  minimum  of  16  MB  of  RAM  to  test  databases 
with  up  to  20K  records.  The  Internal  8k  cache  and  math  co¬ 
processor  should  significantly  reduce  the  processing  times  for 
all  three  strategies  using  either  view  definition. 

We  predict  that  this  approach  could  Improve  the 
performance  of  the  semi-materialization  strategy  well  enough 
to  make  it  feasible  for  use  with  real  time  tactical  systems. 
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For  example,  the  electronic  order  of  battle  maintained  on 
board  a  tactical  aircraft  could  be  completely  updated  during 
or  enroute  to  an  engagement  using  information  received  by  its 
own  sensors  or  sensor  information  passed  from  other  sources. 

This  strategy  could  be  used  in  conjunction  with  the  Joint 
Ocean  Tactical  Surveillance  (JOTS)  system  to  provide  a  real 
time  computer  generated  picture  of  the  tactical  and  strategic 
environments . 

Used  in  this  manner,  JOTS  could  be  placed  on  board  classes 
of  ships  which  do  not  have  the  Naval  Tactical  Data  System 
(NTDS)  Installed  on  board  at  a  tremendous  savings  over  back 
fitting  the  vessels  with  NTDS.  The  information  would  Improve 
the  vessel ' s  mission  performance  by  keeping  the  Commanding 
Officer  constantly  updated  with  real  time  battle  group 
position  data  and  allow  for  the  information  received  by  that 
vessel '  s  sensors  to  be  Incorporated  into  the  tactical  picture . 

We  also  recommend  conducting  more  simulations  on  actual 
databases  with  more  than  two  relations,  and  updates  applied  to 
several  relations. 

Finally,  further  work  is  needed  to  investigate  the 
performance  of  view  processing  strategies  in  the  presence  of 
overlapping  views  over  the  same  relation. 
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APPENDIX  A.  DATA  GENERATION  PROGRAM 
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/^Author:  Curtis  Barcfield 


*/ 


/•Title: 

/•version: 

/•created: 

/•updated; 


Data  Generation  Program  •/ 
MS  C  6.0  /C**  (T2)  •/ 
17  June  91  */ 
11  Aug  91 


•/ 


/•**•«•***#««******«*«*«***««****•««•«**♦*••****•«**«•«*«••****«*•«•****•«*•**«•**««***«*«* 

•  This  program  was  written  to  replace  the  previous  hardwired  test  database  • 

•  generating  program  with  a  more  generic  program.  This  program  generates  the  text  records^ 

•  used  to  create  the  database  used  to  test  the  view  materialization  • 

•  strategies  purposed  by  Professor  Magdi  Kamel.  The  associated  test  • 

•  pg  has  been  written  by  Lt.  Jesse  South.  USM.  a  CSM  student  in  class  PL03.  • 

********«****************«*************«************4*«************************«*********V 


# include  <stddef .h> 

# include  <stdlo.h> 

#lnclude  <stdllb.h> 
tinclude  <tlme.h> 
tincludc  <ctype.h> 

#lnclude  <strln9.h> 

#deflne  size  16  /•  sets  buffer  size  for  output  file  name  •/ 

#define  ALPHA  1  /•  set  buffer  for  type/info  values  */ 

#define  BOUND  6  /•  set  buffer  for  upper/lower  bounds*/ 

/•debug  toggle  */ 

#define  TROUBLESHOOTING  0 

/•  1  sends  debug  data  to  output.txt  file  •/ 

/•  prints  data  used  for  debugging  pg  •/ 

void  print_randoa^generator_array(int.  int*).  print^bounded_array(lnt.  long*); 
/•  used  to  read  data  into  structs  •/ 

Int  rand().  count.  Increment!,  increnent2.  increoentB,  t: 
long  in.  resultsl,  results2,  reaults3: 

/*  modules  used  to  generate  random  values  •/ 
unsigned  timer,  tlme_hack(): 
void  srand( unsigned  int): 

FILE  *input_file,  *outFut_f lie:  /•  file  pointers  for  text  files  •/ 


/ 


'STRUCTS' 


struct  fleld^attrlbutes 

{ 

char  fisld^type [ALPHA] : 

int  field^width: 

char  f  ield_infortnation(ALPHAl ; 

char  .ower^bound [ BOUND ] : 

long  increment: 

char  upper^bound [ BOUND ] : 

struct  f ield_attrlbutes*next: 

^ATTRIBUTE; 

Struct  spec^^type 

( 

long  nunber_of_record8: 
int  number_of^f lelds: 

char  file^nametslre] : 

struct  field  attributes  *first  field: 
struct  spec^type  *next: 

)9PECiriCAT10N; 

/*  declares  modules  used  to  generate  attributes  V 
void  type_alpha(  struct  f ield^attributes  *): 
void  type^nuaeric(  struct  field^attributes  *): 
void  bounded_seguential^arrsy(  long.  long,  int); 
void  tfpe_alphanuaeric(  struct  f leld^attributes  *}: 
void  counter(  int.  int): 
void  random^generatordnt.  int.  int); 

void  print_database_speclficatlons(struct  spec^type  *): 
void  random^long^array ( long.  long,  long): 
struct  spec^type  *list  •  NULL; 
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/ 


'MAIN' 


'/ 


void  malni ) 

( 

char  flle_namelslrej .  f  leld_tfpe!ALPHA) ,  field_infon»atlon[AI.PHA]  ; 
char  c_lower_bound[BOUND) .  c_upper_bound[ BOUND) ; 
long  nuiober^of^recorda : 

int  field  width.  number_of_f lelda.  i.  increment: 

/•  creates  and  defines  ptrs  used  for  linked  lists  •/ 
struct  field_attributes  •new_attribute*  NULL: 

struct  fleld_attributes  •ne*t_field  •  NULL: 

struct  f leld_attributes  ‘end  •  NULL: 

struct  spec_type  •new_epee»  MULL: 

struct  spec_type  ♦top_spec  •  MULL; 

struct  spec_type  *next_spec»  NULL: 
list  •  NULL: 

lnput_flle-  fopen("data_ln" . "r") : 
if ((input_flle)-.NULL) ( 

prlntfCCAN  NOT  OPEN  INPUT  riLE\n" ) : 

)  /‘opn  input  file*/ 

/•  loads  structs  and  creates  linked  lists  •/ 
while) ! (feof (lnput_file) ) ) 

( 

/•  allocates  eeaorr  for  each  specification  struct  ♦/ 

new  spec  •  (struct  spec_type  *)ealloc(ei*eof (struct  spec_type) ) : 

if (top  spec  »•  NULL)  /•  seta  ptr  to  top  of  linked  list  •/ 

{ 

cop_spec  ■  new^apec: 
nest_spac  •  new_apec: 
list  ■  new_spec; 

) 

else 

( 

next_spac'>nest  -  naw_apec:/*  sets  ptr  to  nest  spec  */ 
nest_spec  •  nest__spec->nest; 

( 
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/•  r««<i  in  data  and  loada  atructa  •/ 
if(l  :•  ( facanf  ( lnput_f  ile.  “»ld'' .  &nu!iiber_o£_recordE) ) )  { 
printfC  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."); 

axi c ( 0) ; 

) 

next_8pec-  >nunibar_o£_racorda*nuabar_o£_racorda: 
lf(I  )>  ( f acanf ( input_f lie. ~tld~ . Anuabar_o£_f ielda) ) ) ( 
prlntf(~  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."); 
exlt(O) ; 

) 

naxt_apac->nufflbar_of  f lalda«nuafaer  of_fielda; 

1£(1  !■  ( facanf ( lnput_f 11a. ~Xa" . f lla_name) ) ) ( 
printfC  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."); 
axlt(O) : 

) 

atrcpT(naxt_apec->flla_naae. flla_naae) ; 
naxt_apac->flrat_fiald  •  NULL; 
naxt_apac->next  •  NULL: 

/•  create  linked  Hat  £or  attributea  */ 
for(l*0:  l<next_apec->nuaber_of_fleld8:  ♦»!) 

( 

/*  allocatea  eaeorf  for  attribute  atruct  */ 
naw_attrlbuta  «(etrucC  f leld_atcributec  *)  ealloc  (alzeof (atruct  flcld_attrlbutea) ) 
If (next_apec->flrBt_fleld  ••  NULL) 

( 

next_Bpec->firBt_fleld  -  new_attrlbute;  /•  seta  ptr  to  top  of  Hat  •/ 
end  •  next_epec->flret_fleld: 

) 

else 

( 

end'inaxt  •  new_attrlbute:  /•  aeta  ptr  to  next  attribute  •/ 

end  •  end->naxt; 

) 

/*  load  attribute  struct  */ 

lf(l  !■  ( facanf  (lnput_f  He.  "He".  fleld_tTpe) ) )  ( 

prlntfC"  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."): 
exlt(O); 

) 
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•  trcpy (•nd->  f l«ld_type, f leld_type) : 

Ifd  ;»  ( f  icanf  (  input_f  ll€.  "»d"  .  &f  ieldwidth) ) )  { 

prlntff"  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."): 
exlt(O) ; 

) 

«nd->  f ield_width*f ield_wldth: 

lf(l  !•  ( facanf ( tnput_f lie, . f ield_lnfon»atlon) ) ) ( 

prlntfC’  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."): 
eslt(01 : 

) 

■trcpy (end- >  f lald_lnforaiatlon. f ield_lnforaation) : 

lf(l  :•  ( (acanf ( lnput_f lie. "»a" ,c_lower_bound) ) ) ( 

print! ("  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."); 
exlt(O) ; 

> 

■trcpy(end->lower  bound. c_l owe r_bound) : 

1!(1  !•  ( facanf ( lnput_!lle. "Ed" .filncreeent) ) ) ( 

prlnt!(~  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."); 
■xlt(O) ; 

) 

end- > increment  •  Increment; 

lf(l  !•  (fecanf (input_file. ■*»".c_upper_bound) ) ) < 

prlntf(~  UNEXPECTED  VALUE.  PROGRAM  TERMINATED."); 
exlt(O) ; 

) 

■  t rcpy  ( end-  >  uppe r_bound .  c_uppe  r_ba\ind ) ; 

end  ->next  >NULL; 

) 

) 

fcloee(lnput_fllel ; 

/*  Redirects  monitor  output  to  text  file  celled  output.txt  */ 

•If  TROUBLESHOOTING 

f reopen ( "output. txt" . "w".«tdout) ; 
prlnt_database_epecl fleet lone ( list ) ; 
fO; 

•define  DEEP_DEBUG  1 

•endlf 
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/*  uses  sratttm  tin*  to  ganarate  random  number  *J 
timar-tima_hack( ) ; 
srand( tlmar) ; 

/*  uses  linked  list  to  read  each  spec  (BEGIN  PG  EXEC  )  •/ 
whiledlat  NULL) 

( 

resultsl'O:  /•  sets  module  "counter"  to  taro  •/ 

reBulta2>0; 

rasults3>0; 

lncrefflantl>0; 

lncrament2«0: 

increments *0; 

output_f ile«  f open ( list- >{ile_name.  "w" ) ; 
if ( (output_fila)**NULL)( 

printfC'ClUl  NOT  OPEN  OUTPUT  FlLE\n" ) ; 
exitfOl ; 

)  /'opn  output  file*/ 

/•  BUILD  DATABASE  TEXT  PILES  •/ 
for(ln»0;  ln<llst->nuabar_of_racords;<'<'ln) 

( 

naxt_field  •  list'->first_flald; 
count >0; 

whlla(naxt_fiald  !>NULL) 

( 

if (naxt_flsld  ->  flald_tTpeCOJ*»’A’ ) 

( 

t7pa_alpha(  naxt_flald); 

I 

alsa  if (naxt_fiald  ->  f iald_typa[0] N' ) 

( 

tppa_nuMric(  naxt_field); 

} 

alaa  if (naxt_f ield  ->  fiald_tTpa[01**'O’ ) 

( 

tppa_alphanumaric(naxt_fiald) : 

) 
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ne«t_fleld  ■  ne«t_field->next; 
if (n*xt_field  :*NULL)( 

f print f (output_£ile, " : " ) : 

> 

> 

fprintf (output^file , "\n" ) : 

I 

lixt  »  ll«t->next; 
fcloae(output_fil«) ; 

> 

•xit(O) ; 

*  Tim*  Hack  uaea  th*  ayatca  clock  to  provide  the  aeed  value 

*  for  the  rand  and  arand  library  function*.  * 


unaigned  tia*_hack() 
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elock_t  r*nd_lnput: 
unaigned  ***d_lnput: 
rand_input«cloek( ) ; 

***d_input> (unaigned) rand_input; 
return (***d_input) : 

> 

*  Bounded  aequential  array  * 

*  create*  a  bounded  array  which  ia  uaed  with  th*  randO  library  * 

*  function  to  aelect  from  a  uaer  apecified  number  of  array  * 

*  elamanta  to  return  a  value  from  within  that  array.  * 

•••*••••*«•*«**«*•*•••*•••**•**•••»••••••••••••*••••••••••••••••••••••••/ 

void  bound*d_aaquantlal_array(long_lncr*a*nt.  long_lower_bound .  Int  nuaber_of_valu*a  ) 

( 

int  a.  long_ind*a; 

long  *long_*torag*. long_low; 

/*  allocate  atorag*  apace  in  memory  for  array  */ 
long_atorag*>(long*)calloc(numb*r_of_valu*a.aix*of (long) ) ; 
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/•  fill  «rr»T  V 

long_»  corage  1 0 )  •  1  ong_l  ow*  1  ong_lowe  r_bQund : 
for(i!i»l:  Bi<  number_of_valuea : 

{ 

long  sCoragetci]  •long_low  ♦•long_lncreoent: 

) 

/*  aelect  value  fa  array  using  generic  random  generator  •/ 

long_indax>( rand( )tnumber_of_valuea) ; 

fprintf (output_file. "»051d“ . long_storage(long_lndex| ) ; 

#if  DeEP_OCBUC 
lf(t<l)( 

print_bounded_array (number_of_valuea.  Iong_atora9e ) ; 1 

t»*; 

#endif 


•  Type  alpha  generates  alpha  character  atring  to  fill  user  • 

*  determined  field  site  • 

•eeeeeeae*e*e*e*eee*eeeeaee#e#eeeeee.eee#eeeee»*#eeeee*e***e***..eeee*e.ee/ 

void  type_alphe(  struct  field_actributaa  •nemt_fleld) 

( 

char  c; 

static  char  start«'A'-l; 

int  j,  incrsment.  lower^bound.  upper  bound; 
int  nuaber^of__values: 
lon9_increment.  long_lower  bound; 

/•••••••  Conversions  for  Random  Oensrator  •••••••*••••/ 

lower_bound*(int) (nest_f ield  ->lover_bound[0] ) ; 
uppar_bound-(int)  (next_fleld  •>>upper_bound(0] ) : 
incrament>next_field  -> increment: 

/•••*•*••••*••  Conversions  for  Bounded  Array  ••••••»•/ 

long_lowar_bound*(atol) (naxt_fiald  ->lower_bound) : 
lon9_incremant*naxt_fiald  •> increment; 
numbar_of_Taluas-(atoi) (nost_fiald  ->uppar_bound) ; 

if (next_fleld  ->fiald_infoniatlon(0]«>'R* )  /*  Random  field  selected  */ 

{ 

randoa_genarator( increment ,  lovsr_bound,  upper_bound) ; 

t 
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•  Ise  If  (n«»t_fl«ld  ->fleld_lnfon!i«tionC01—  B’ )  /•  Bounded  eequential 
•elected  */ 

( 

bounded_»equenti«l_arrey ( long_increment ,  long_lower_bound.  number 

> 

elic  if (na*t_£ield  -> f leld_infor«atlon[OI»« ’X' : I ' D ' I 
/•  countup  counter  places  chars  'A’-'f  in  field  */ 

( 

for( J“0; J <nest_f leld  ->f leld_width; ♦♦J )  /•  sets  field  width  •/ 

( 

if (start  >*'2' ) 

( 

start*  'A' : 

) 

else 

( 

**start ; 

) 

fprtntf(output_f lie, “Xc" .start) :  /•  prints  alpha  char  to 
output  flla  */ 

) 

) 

) 

/•••••••••«•••••••••••••••••••••••••••••*•••••••••••••*••••••••••• 

•  Type  nuaaic  ganaratea  nuaarlc  charartars  to  fill  usar  * 

*  datanilnad  fiald  slsa  * 

void  typa_nuBarlc(  struct  f lald_sttrlbutas  •nast__f laid) 

( 

char  c: 

static  start*'0'-l; 

Int  },  lowar  bound.  Incraaant.  uppar_bound; 

Int  nu»bar_of_»aluas.  lncra«ant_e.  lowar_bound_c: 
long  Incraaant.  long_lowar_bound.  lncraaant_long_arrsy : 
long  lowar_bound_long_arrsy.  uppar_bound_long_array: 


field 


of  values) 
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/**♦«••••«••••  Conversions  for  Counter  ♦*****♦•*•♦*•♦*/ 

lncrement_c  ■  next_fieXd->lncretDent: 
lower_bound_c  ■(atoi) (next^field->lower_bound) : 

/****»#*  Conversions  for  Random  Generator  ************/ 
lower_bound* { int ) (next^f leXd  ->Xo«er_bound[Ol ) : 
upper^bound* ( int ) (next_f ieXd  - >upper_bound[0] ) : 
increment>next_f leXd  <*> Increment: 

/•e**ee***«*e*  conversions  for  Bounded  Array 
Ion9_Xower_bound*(atol} (next^fleXd  •>Xower_bound) : 
lon9_increment«next_f laid  -  >  Increment : 
nwusber_of_valuea«  (atol )  (next^^fleld  *>upper_bound) : 

/eeeeeeeeeeeee  Conversions  for  Random  Long  Array  •*♦•*♦•♦/  « 

lover^bound^Xong^array  « (atol) (next^field  •>lower_bound) : 

Increment^long^array  •(long) (next^field  •>increnent) : 
upper^bound^long^array  «(atol) (next^fieXd  •>upper_bound) : 
if (next^fleld  ->fleld_lnformatlon(0]««'S‘ )  /*  sequential  counter  */ 

{ 

counterdnerement^c.  lower^bound^c) ; 
count** ; 

) 

else  If (next^fleld  ->fteld^lnfoniation{OJ««*R' )  /•  Random  */ 

{ 

rando«_generator(  Increment,  lover^bound,  upper^bound) ; 

) 

else  if [next^f leld  •>fleld_lnformation(0]««’B' )  /*  Bounded  sequential  */ 

( 

bounded_sequentlal_array(  long^increment.  long_lower_bound.  number_of_values  ); 

) 

else  if  (next^field  ’->fleld^lnfoniation[0)««’X' )  /*  Random  long  array  */  % 

{ 

random^Xong^array  ( increment^long^array .  lower_bound_Xong_array,  upper_bound_long_array  ) :  ^ 

) 

else  If  (naxt^fleld  ->flald_lnfomatianC0)««'0‘ ) 
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/*  countup  counter,  fills  field  with  'O'  -  '9'  in  sequence  */ 

{ 

for(  J  *0;  J  <ne*t_fleld  -  >  f leld_width:  j  )  /•  sets  field  width  •/ 

( 

if (start  >-'9' ) 

{ 

start*  O' : 

t 

else 

( 

♦♦start: 

) 

fprlntf (output_flle. "»c“ . start) :  /•  prints  nuneric  char  to 
output  file  */ 
i 

) 

) 

/••*eee**eeee*ee*a*eae*e*eeeeeeee*eee***ee*esaee***eeeeeee*****ees*e**s* 

*  Trps  alphsnuaerlc  generates  alphenuaarlc  chararters  to  fill  * 

•  user  detarainad  field  site  * 

seeeseeeeeaee*eeee*ee*eseeeseeeeeeeee*eeeee#eee*eseeee*e***ee**ee*esee**/ 

void  tTpe_alphanuaerlc( struct  fiald_attributas  *naat_fleld) 

( 

char  c.  d; 

Int  J.  k  /•,  count«0*/  ; 

static  char  alpha-’A’-l; 

static  char  nuaarlc* ' O' •! ; 

int  alpha_fiald_width.  nu»erlc_f leld_wldth: 

alpha_fiald_width«(atol) (naat^fleld  ->lower_bound) ; 

nuaarlc_flald_wldth>(atol) (naat_fleld  ->upper_bound) ; 
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for(  j  *0:  j  <«lph*_f  iel(l_wldth;  ♦♦J )  /•  generate*  alpha  chare  h'-'Z’  */ 

{ 

if(alpha  >-  2-  ) 

( 

alpha* '  K  ■. 

) 

elec 

( 

•*alpha; 

\ 

fprlntf  (output_f  lie.  ''»c" , alpha) : 

) 

for(k*0:k<nu»*rlc_f  leld_width:  ♦♦)»)  /•  nuaerlcs  •0'-’9’  */ 

( 

If (nunerlc  > • ' 9 ' ) 

( 

nuaerlc* ' 0 ' ; 

> 

ale* 

( 

**nuMrle: 

) 

fprlntf  (output_fH*.  "Kc"  .nuaerlc) ; 

) 

) 
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Random  generator  takes  s  lower,  upper  and 


*  Increment  int  value,  creates  an  numeric  array  and  * 

*  uses  the  functions  rand{)  and  srand()  to  * 

*  select  an  array  element  which  ^^ybe  converted  to  a  * 

*  alphanumeric  char  for  printing  to  the  output  file.  * 

***«*****««*****a«**********«********************e«********a********a***/ 

void  random_generator(  int  Increment,  int  lower^bound.  int  upper^bound) 

( 

/*  Declare  module  data  elements  */ 
int  numeric^lndex: 
int  output_f rom^array: 

int  generata_numerlc_array( int . int. int) ; 
char  alnum^character^output: 

/*  Compute  array  siae  */ 

numeric  index*  ( (upper_bound*lower_bound)/increment) : 

/*  Determine  if  a  set  of  bounded  random  numbers  are  required  */ 

if ( ( ( lower  bound > 47) 4ft (uppe rebound < 58) )  (lower^bound>64)ft&(upper^bound<91) ) 

< 

output^f rom^array*  generste_numerlc^array(nu»arlc_lnde*.  Increment,  lower^bound) 
slnum_chsracter_output«(char) (output^frcm^array) : 
fprintf  (output^f  He.  ”^040**  .alnum^character^output) ; 

) 

else 

output  from  array*  generate  numeric_array{numeric_^lndes.  increment,  lower^bound) ; 
fprintf (output^f He.  "ROdd" .  output_from_array) ; 


/ 


Random  long  array  takes  a  lower,  upper  and 
increment  long  value,  creates  an  numeric  array  and 
uses  the  functions  rand()  and  srand()  to  * 


*  select  an  array  element  which  is  printed  to 

*  the  output  file. 

*************************************«*««««*«******«**««««««*«««««««««««^ 
void  random_long_array {  long  increment_long_array .  long  lower_bound  long  array.  long 
upper_bound_long_array) 

{ 

/*  Declare  module  data  elements  */ 
int  m.  index: 
long  numeric^index.  low; 
long  *output^f ro«_array : 
long  output^from  random: 

/•  Compute  array  sire 

numeric^index*  { (upper_bound_long_array-lower_bound^long_array)/increment_long  array) ; 
if ( numer ic^index<  20 ) 

( 

/*  Allocate  memory  block  for  long  array*/ 

output_f rom_array«  ( long* 1 cal loc(numeric_index.slzeo£( long) ) : 

/*  Set  lower  bound  of  array  */ 

output^f rom^array (01 ■  low*  lower^bound^long  array; 

/♦  Load  array  */ 
f or(m«l ; n<numeric_index:m*«) 

{ 

output^from_array(n]«  low**  increment_long_array: 

} 

index*  (rand( )tnumerlc_lndex) : 

fprl-^tf  (output_f  lie.  "%04ld’' .  output_from_array(  index) ) ; 

) 

else 

output_from_random*  (l*(rand(  Hupper^bound_long_^array) ) ; 
fprlntf  (output^f  lie.  ■'A041d‘’  .output_from_^random) : 

> 

) 
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Counter  uses  lower  bound  and  incretikent  to  act  as 


/ 


♦  a  sequential  counter  for  max  of  numbers  per  apec_type.  * 

•*•*****•«««*««***«««******«****•****************************•***•*******/ 

void  counter(  int  increment  c.  int  lower_bound_c) 

( 

/*•***#**««•«*  first  counter  ***•♦•*****/ 

if ( ( ln*«0}&&( resul t si ««0) 6&( count *»0) ) 

{ 

resultsl  *  lower_bound_c: 
increment!  ■  increoent_c; 

} 

else  if(count*«0) 

{ 

results!  «  reaultB!*incrementl: 

if (count*«0) { 

fprintf  { output^f  l!e,  "»041d‘* ,  results! ) :  ) 

/«•«**•**•*«  second  counter  •*•**♦**•***/ 

if ( ( ln««0}6&( resulta2*s0) 6&( count ■«! ) ) 

{ 

results2  ■  lower^bound^c: 
increment2  •  increnent^c: 

) 

else  if(count»«l) 

( 

re8ults2  ■  resu!ts2«increaent2 : 

) 

i f ( count**! ) { 

fprlntf  (output_f  lie.  "1;041d”  ,  results2} : ) 

/«*««*•««*••*  tHIRO  COUNTER  *•****•*••**/ 

if  (  (  in**0)  &&  (  reBult83**0 )&Ct( count *«2) ) 

{ 

results3  •  lower_bound_c: 

IncreaentS  ■  Increaent^c: 

) 
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else  lf(count>>2) 


{ 

resultsB  *  results3-»increoent3: 

i£(count»®2) < 

fprintf  (output_f  ile .  ’'%041d'' .  resulteS) :  } 

/***************•*****••*******«*********/ 

z************************************************************************ 

*  Generate  numeric  array  produces  ^  bounded  * 

*  array  and  uses  the  randO  function  to  simulate  a  real  * 

*  random  number  generator  * 

***•****•*************«********«*********•*****««********************•***/ 
int  generate_numerlc_array(int  numerlc__index,  int  increment. 

Int  lower_bound) 

int  m.  indea; 

int  *numeri castor age,  low; 

numerlc^storage* ( lnt*)calloc(numeric^index.si*eo£(lnt) ) : 
numeric_storage(0] •  low  •  lower^bound; 

£or(m«l:  m<numeric^indc:: 

{ 

nuaeric^storage[a]«low  increment; 

} 

index* ( rand ( ) ^numeric_index ) ; 
return (numeric  storage! index) ) : 

#i£  DEEP_OEBUG 
if(t<l)( 

print_randoe_9enerator_array(numerlc_index,  numerlc^storage ) : } 
t^* : 

#endif 


} 
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/••••**•••••••  PRINT  RANDOM  GENERATOR  ARRAY 

void  print_random_generator_array(int  numeric_indar, int  *numeric_Btorage) 

( 

int  1 : 

for ( i*0 : i (numeric^ index: i** )  { 

princf('‘  array[%dl  ■  %d\n‘* .  i  .r\uiocric_storage[  1 1 ) : 

1 

) 

/••••••••*•*••••*  PRINT  BOUNDED  ARRAY 

void  print_bounded_array  (  int  nuinber_of_valuea.  long  *long__atorage) 

( 

int  i : 

for ( iaO: i <number_of_valuea: i*> ) { 

printfC  array[%d1  -  »051d\n"  .  i .  long_atorage[il ) : 

> 

> 

*  Prints  specifications  including  all  attribute  link  lists  * 

seeeeeeeeeeeeee*e**e*eee*eeeee*eeee*#e«e##*ee*eeee**e****e*e***ee*e.e/ 

void  print_database_spscificstlons(struct  spsc_typs  ‘list) 

( 

struct  f ield_attributes  *next_field: 
int  i,  1«0: 

printf ("Printing  link  lists  for  generic  database  generator\n" ) : 
while  (list  !-NULI,) 

( 

i-0: 


printf ( "\t3PEC  M\n".»»l): 

printf ("\tThere  will  be  Eld  records\n",list->nuaiber_of_records) 
printf ("\Tthsre  will  be  Ed  f lelds\n" , llst->nuBber_of_f lelds) ; 
printf ("\tThe  file  nans  is  Es\n" . llst->f lle_naaB) : 
nezt_flald  ■  liBt->flrst_fleld: 
while(next_field  !-mJLL) 

{ 

printf ("\tPleld  Ed:\n".»*l): 

prlntfCVtEs  is  field  type\n".next_fleld->fleld_type)  ; 
printf ("\tEd  is  field  wldthXn" .next_f leld-> f ield_wldth) : 
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printf ('At**  i*  info\n" .ne»t_field-> f ield_information) : 

prlntf("\t*a  !•  lower  bound\n" .next_fleld->lower_bound) : 
printf  ( ‘At^fld  ie  incrementXn"  ,next_field->  increment)  : 
printf ( "Nt^a  la  upper  boundXn" .neat_field->upper^bound) : 
next_field  •  next_field->next: 

> 

liat  •  llat->next: 

) 

) 
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APPENDIX  B 


» 


VIEW  MATERIALIZATION  SIMULATION  PROGRAM 
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/♦  Title  :  View  Meterialliatlon  SiauZatlon  (vsgapdp?)  */ 

/*  Author  :  Jeeee  T.  South 

/*  Date  :  17  June  1991 

/*  Reviaed  :  25  July  1991  */ 

/*  Modified  :  for  general  expreealona  22  AUG  by  Curtis  Barefield  */ 

/*  Purpose  :  Thesis  Research  */ 

/*  System  :  IBM  80286  clone/  603d6SX  */ 

/*  Compiler  :  Microsoft  C  6,0,  INGRES  precompiler, ( Borland  C**)  */ 

/*  Description  :  The  program  is  part  of  a  thesis  */ 


ilnclude  <stdlo.h> 

#lnclude  <  stdlib . h> 

#lncludc  <time.h>  s 

#lnclude  <aiath.h> 

exec  sql  include  sqlca: 

#define  size  16 

idefine  dbinfo  "info.dat" 

idefine  cntrlfl  “cntrl.dat" 

#define  update^flle  ''data_ln*' 

•define  finrslt  "fnlrslt.dat" 

•define  runrclt  ’*mrslt.dat“ 
exec  sql  begin  declare  section: 

•define  empinfo  ’'eapdat.dat" 

•define  posinfo  ’’poedat.dat*’ 

•define  shilinfo  ** skildat.dat'’ 

•define  updatinfo  "update. dat" 
exec  sql  end  declare  section: 
void  open_fHss(PILE**,  FILE**,  FILE**): 
void  close_ftles(FILE**.  FILE**,  FILE**); 

void  init_test_d«tabase(int) :  i 

void  scan  dblnfo( long*,  long*,  long*,  int*.  int*.  int*.  long*,  long*,  long*); 

void  create_tablee(void) :  ^ 

void  create_views(int) ; 

void  creete_update_table(void) : 

void  copy_bese_tables(void) : 

void  copy^semi_n_ful inmate ( int ) : 

void  create^tabie^index<void) ; 

void  ■odule_qRi(char.  int,  long,  double*.  FILE*): 
void  module  sm(char.  int,  long,  double*.  FILE*); 
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void  module_fn(char.  int.  long,  double*.  FILE*): 

void  write  file_headings(cher*.  char*.  FILE*.  FILE*): 

void  write  run_reault (char.  char.  int.  long,  double,  long.  FILE*): 

void  write  f inal_reaul t ( int .  int.  long.  int.  long.  long.  long,  float. 

float,  float,  float,  float,  double,  double,  double.  FILE*.  FILE*): 
void  coaipute_avg_t  ime  (  int .  double*,  double*,  double*): 

void  compute_fv_and_fg  and_P(lnt.  int.  int.  int.  float*,  long.  long.  long. 

long,  float*,  int.  int.  float*): 

void  coi»pute_table_counta (long*,  long*,  long*,  long,  float*,  float*): 

'  void  refreeh_update_te»t_file( long.  long,  long): 

void  main (void) 

►  { 

int  K.  0.  updat_ei*.  i.  run_cnt  •  0.  jero  »  0: 
int  vmax.  vbaee.  vincr.  viewcut: 

long  ecard.  pcard.  ecard.  countb.  count v.  councq: 

long  qnax.  gbaee.  gincr.  guerycut: 

float  fv.  fva.  fg.  fga.  P: 

double  tibaqm.  tioeea.  tieefa: 

char  QUERY  •  'O',  UPDATE  •  'K': 

char  *pnn_ptr,  parameter ( 10 1 .  *updt_ptr.  updat_relI10) : 

FILE  *cntrl_fl.  *fraault_fl.  •run_ralt: 
pnn_ptr  •  Spara«atar(01 : 
updt  ptr  ■  Pupdat^raltOI : 

open  fllea(&run_ralt.  6cntrl_fl,  6f raault_fl) : 

acan_dbinfo(apcard.  &acard.  aacard.  «vaax.  avbaae.  Svincr.  fiqaax.  eqbaee. 
Sqincr) : 

while( .'  feof  (cntrl_fl ) ) 

{ 

*  tiaegn  •  tineas  •  tinefa  •  0.0; 

countb  ■  countv  -  countg  ■  0: 

.  facanf  (cntrl_fl.  "Ed  Eld  Ed  Ed  Ed  Ea  Ea" .  Evlewcut.  aquerycut.  ax,  aO. 

aupdat_aix.  pm_ptr.  updt_ptr); 

•  if  (run_cnt  -•  lero)  wrlta_f lle_headinga(pm_ptr.  updt_ptr.  freault_fl. 

run_ralt) : 

inlt_teat_databaae( viewcut) ; 
nin_cnt»» ; 

printf("\n  run  «  EdVn",  run_cnt): 
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ford  *0:  1  <  K:  !♦♦) 

{ 

ref re»h_updat«_text_f ile(pcard.  i.  updat^ai*) : 
module_qm( UPDATE,  viewcut.  querycut,  &tiJBeqn.  run_r»lt): 
nodule  am(UPDATE.  viewcut.  querycut.  fttlnesm.  run^rslt); 
module_fm( UPDATE,  viewcut.  querycut.  &tioefu.  run^relt): 

) 

ford  ■  0;  1  <  Q;  !*♦) 

{ 

nodule  qa(QUERY.  viewcut.  querycut.  Atiaeqn.  run_relt): 
module_en(QUERY.  viewcut,  querycut.  &tineea.  rxm^ralt); 
nodule_fn(0UERY.  viewcut.  querycut.  Atimefn.  run_rslc): 

conpute  av9_tlae(Q.  Atiaeqa.  Atiaean.  fitlaefa); 

conpute_fv_and_fq_end_P(vaex.  vbaee.  vlncr.  viewcut.  &fv.  qnex.  qbaae. 
qincr.  querycut.  6fq.  K.  Q.  &P): 

coapute  t«ble_^counta(6countb.  Rcountv.  ficountq.  querycut.  6fva.  &fqa) ; 
write^f lnel^reeult(run^cnt.  viewcut.  querycut.  updat^al*.  countb.  countv. 

countq.  fv.  fve.  fq.  fqa.  P.  tiaeqa.  timesa.  tinefa. 
freeult^fl.  run^relt) : 
exec  eql  disconnect: 
systeaC'raingres** ) : 

) 

close_f iles(ftrun_rslt,  Rcntrl_fl.  ftfresuXt_fl) ; 
printf ("Xndisconnect  coaplcteVn" ) : 
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void  lnit_t«st_d«tab«s« (Inc  vlewcut) 

( 

■7stcn(  "dcatroydb  magdl'’): 
syscan(  "creacadb  tBagdl"): 
ay8Cem(  "addingrea  >064000'*): 
exec  aql  whenever  sqlerror  atop: 
exec  aql  connect  magdl; 
create_tabXea( ) : 
create_vlewa( vlewcut) : 
copy_baae_tablea( ) : 
copy^aemi^n_full^nata( vlewcut) : 
create_table_lndex( ) : 

) 

void  open_fllea(FILE  **run_ralt,  FILE  **cntrl_fl.  FILE  **freault_f I ) 

{ 

•cntrl^fl  ■  fopen(cntrlfl .  "r"): 

*freault_fl  ■  fopen{flnralt,  ‘‘a"); 

•run^ralt  •  fopen(runralt.  "a"): 

If  ( ( r*run^ralt)  ;;  ( *cntrl_fl )  ;;  ( !*freauit_^fl) ) 

{ 

printf ("NnERROR:  control  or  output  file*  did  not  open**}: 

fclosealK ) : 

exec  aql  dlaconnect: 

exlt(l); 

> 

> 

void  cloae_flle8(riLE  •*run_ralt.  FILE  **cntrl_fl.  FILE  **freault_fl) 

Int  1 : 

fprlntf (•freault_£l. "Nn" ) : 

for  (1«0: 1<0O;  !♦♦)  fprlntf  ( *freault_fl ,’■*’* ) : 
fclose  (•nin^ralt): 
fcloae  (•cntrl_£l) : 
fclose  ( *f result^f 1 ) ; 

) 
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void  •c«n_dbin£o( long*  ecard,  long*  pcard.  long*  scard.  int*  vmax,  int*  vbase. 
int*  vincr.  long*  qmax,  long*  qbaaa.  long*  qlncr) 

FILE*  db_info; 

db_ln£o  «  fopen(dbin£o.  “r"); 
if ( :db_info) 

printf { " \NERROR:  dbinfo  file  did  not  open 

fcloBoall ( ) : 

exec  aql  diaconnect; 

exitd); 

) 

fecanf  (db^info.  "1[ld  %Id  %ld\n’*.  &*ecard.  6*pcard.  &*acard)  : 
fecanf fdb^info,  "Xd  %d  ikd\n'*,  &*vnax,  6*vbaac.  &*vincr); 
facanf(db  info,  ''%ld  %ld  %ld",  &*qiDax,  6*qbaee,  &*qlncr) : 
fcloae(db_info) : 

) 

void  create^tableai ) 

{ 

/*  create  query  eodification  tables  */ 
exec  sql  create  table  poeqa 

(e^nun  Inte9er2,  snua  lnteger2.  level  integerl.  keyno  Inte9er2, 
acclnfo  c66); 

exec  sql  create  table  eapqa 

(e_nua  Inte9er2,  dnua  integerZ,  enane  c20,  address  c70. 
salarr  integer4.  title  c30,  Jobdesc  c60): 
exec  aql  create  table  sklllqa 

(snua  inte9er2,  snaae  e20.  stype  c34): 

/*  create  aeai-aaterisllzatlon  tables  */ 
exec  sql  create  table  possa 

(e_nua  Intc9er2.  snua  lnteger2.  level  integer!,  keyno  Inte9er2. 
acclnfo  c66); 

exec  sql  create  table  eapsa 

(e_nua  integer 2.  dnua  integer 2,  enaae  c20.  address  c70. 
salary  intag«r4.  title  c30.  Jobdesc  c60): 
exec  aql  create  table  skillsa 

(snua  inte9er2.  snaae  c20.  stype  c34): 
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ex«c  sql  create  table  pos  prim 

(e_nua  intcger2.  keyno  lnteger2): 
exec  eql  create  table  enp^priu 

(e_nun  integer2.  enacae  c20.  salary  lnteger4): 

/*  create  full  naterialitatlon  tables  */ 
exec  sql  create  table  posfn 

(e_nua  lnteger2.  snun  Integer 2.  level  integerl,  keyno  integer2. 
acclnfo  c86) : 

exec  sql  create  table  ampfm 

(«_nua  lnteger2.  dnua  lnteger2.  enaae  c20.  address  c70. 
salary  inte9er4>  title  c30.  jobdesc  c60): 
exec  sql  create  table  sklllfn 

(anua  lnteger2.  snane  c20.  stype  c34): 
exec  sql  create  table  full^aat 

(e_nua  integer2.  enaae  c20.  salary  lnteger4.  keyno  Inte9er2): 

void  create_vlews(lnt  vlewcut) 

( 

exec  sql  begin  declare  section: 

Int  view^cut: 

exec  eql  end  declare  section: 


view  cut  •  vlewcut: 


void  cr««te^upd«tc_tablc( ) 

{ 

•Jc«c  «ql  cr€«t«  tablo  updat«_tbl 

(«_num  lnt«g«r2.  anua  lnt«ger2.  l«v«l  Integerl.  kayno  integer2. 
accinfo  c66) : 

•sac  aql  copy  tabla  updata^tbl 

(o_nua  ■  cOcolon.  snuB"  cOcolon.  laveX  »  cOcoIon. 
kayno  ■  cOcoXon.  accinfo  ■  cOnX) 
froB  :updatlnfo: 


void  copy_bata^tabXaa( ) 

axac  aqX  copy  tabXa  posqm 

(a^nuB  ■  cOcoXon.  anua  ■  cOcoXon.  XavaX  •  cOcoXon.  kayno  ■  cOcoXon. 
accinfo  •  cOnX) 
from  :poalnfo: 
asac  aqX  copy  tabXa  poaaa 

(a  nuB  ■  cOcoXon,  anua  ■  cOcoXon.  XavaX  «  cOcoXon,  kayno  •  cOcoXon, 
accinfo  ■  cOnX) 
froB  :poalnfo; 
aaac  aqX  copy  tabXa  poafa 

(a  nuB  ■  cCcoXon  anua  ■  cOcolon.  XavaX  •  cOcoXon.  kayno  *  cOcoXon, 
accinfo  ■  cOnX) 
froB  rpoainfo: 
axac  aqX  copy  tabXa  aapqa 

(a  nuB  •  cOcoXon.  dn\M  ■  cOcoXon.  anaaa  «  cOcoXon,  addraaa  •  cOcoXon. 
aaXary  «  cOcoXon,  tltXa  ■  cOcoXon.  Jobdaac  •  cOnl) 
froa  taaplnfo: 
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•xec  sqi  copy  t«bl«  •opan 


(€_num  «  cOcoXon.  dnum  *  cOcoIon.  enaae  »  cOcoion.  address 
salary  ■  cOcoion.  title  •  cOcoion.  jobdesc  =  cOnl ) 
froa  cesiptnfo; 

exec  sql  copy  cabl«  empfoi 

(e_num  •  cOcoion.  dnum  >  cOcoion.  ename  «  cOcoion.  address 
salary  «  cOcoion.  title  *  cOcoion.  Jobdesc  *  cOnl) 
from  :empinfo: 

exec  sql  copy  table  skillqm 

f  (snua  •  cOcoion.  sname  ■  cOcoion.  stype  «  cOnl) 

from  :akillnfo: 

S  exec  sql  copy  table  skillam 

(snum  >  cOcoion.  sname  •  cOcoion.  stype  •  cOnl) 
from  iskilinfo: 

exec  sql  copy  table  sklllfm 

(snum  "  cOcoion.  sname  *  cOcoion.  stype  «  cOnl) 
from  :sklllnfo: 

void  copy^seBl^n_fuH_»ats(int  vlewcut) 

( 

exec  sql  begin  declare  section: 

Int  vlew^cut; 

exec  sql  end  declare  section: 

view_cut  ■  viewcut; 

exec  sql  insert  into  pos_prlB  (e_num.  keyno) 
select  e  nuai.  keyno 
from  possm 

where  level  >*  ;vlew_cut: 

^  exec  sql  insert  Into  emp^prlm  (e^num.  ensue,  salary) 

select  e^num.  ename.  salary 

^  from  empsm: 


cOcoion 


cOcoion 
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from  gmpfm.  poafa  outer2 
where  exiats 


from  PQ«fm  lnner2 

where  emofa.e_nug>  «  tnner2.e  num 
end  Quter2.keyno  »  inner2 . keVhQ 
end  lnner2.  level  )■  ;view  CuC-Ll 


void  creete_t«ble_inde*{ ) 

( 


exec 

aql 

modify 

empqm 

to 

cbtree 

on 

e  num; 

exec 

eql 

modify 

empam 

to 

cbtree 

on 

«_num; 

exec 

aql 

modify 

eapfm 

to 

cbtree 

on 

e_nuB: 

exec 

aql 

modify 

poaqm 

to 

cbtree 

on 

level: 

exec 

eql 

modify 

poaam 

to 

cbtree 

on 

level; 

exec 

eql 

modify 

poafa 

to 

cbtree 

on 

level ; 

exec 

•qi 

modify 

•■p_prla 

to  cbtree 

on  aalary 

exec 

aql 

modify 

po»_prlB 

to  cbtree 

on  e_nua: 

exec 

aql 

modify 

to  cbtree 

on  aalary 

/*  - 

create  i 

■•condarT 

indexea 

•/ 

exec 

aql 

create 

index 

eapqadx 

on  eapqn  (e_nua): 
exec  aql  creete  index  espeadx 
on  eapsB  (e_nuai): 
exec  eql  create  index  eapfndx 
on  espfe  (e_nuii): 
exec  aql  create  index  poaqadx 
on  poaqa  (level); 
exec  aql  create  index  poaaedx 
on  poeaa  ( level) : 
exec  aql  create  index  posfedx 
on  poefe  ( level ) : 
exec  aql  create  index  e^priedx 
on  eap^prie  (aalary); 
exec  eql  create  index  p^^priedx 
on  poe_prie(e_^nu») ; 


A 
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•(•c  aql  create  Index  f_matdx 
on  full_mat  (aalary): 

) 

void  inodule_qm(char  cntrl_char,  Int  viewcut.  long  querycut.  double  •timeqm. 
FILE  •run_ralt) 

( 

clock  t  tatart  ■  0.  tatop  •  0: 

double  elap_tliDe: 

long  tbl_cnt  «  0: 

exec  aql  begin  declare  aectlon; 

Int  vlew_cut: 
long  query_cut; 
long  qnum: 
char  qname[21]; 
long  qkeyno; 

exac  aql  end  declare  aectlon; 
exec  aql  declare  qB_cl  curaor  for 
aelect  e_nua.  enane.  keyno 
from  full_»lew 
where  aalary  >•  : query _cut: 
vlew_cut  •  viewcut: 
query _cut  •  querycut: 
awi tch ( cnt  rl_char ) 

( 

caaa  ' K‘ : 

create_update_table( ) : 
exac  aql  Inaert  Into  poaqw 
aelect  * 
froa  update_tbl; 
exac  aql  drop  update_tbl; 
break; 
caaa  'O': 

tatart  -  clockO: 
exac  aql  open  qB_cl; 

exec  aql  whenever  not  found  goto  cloaeqa_cl: 
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while(Bqlc4.*4lcode  <>  0) 

( 

exec  eql  fetch  qm_cl 

into  :qnum,  :qname.  iqkeyno: 

/•  prlntf  ( ''Nnnumber  •  %d“  .  qnum) ;  V 
tbl_cnt»* : 

) 

closeqm_cl : 

exec  sql  whenever  not  found  continue; 
tetop  >  ciockO: 
exec  sql  close  qm_cl; 
break; 
default: 

printf ("\nlncorreot  control  character\n” ) ; 
break; 


) 

alap  tine  •  (tstop  •  tstart) /(douLle)CLK_TCK; 

*tlaeqB  •  *tlaeqB  ♦  elap_tlBe; 

writs  run  rasultCq'.  cntrl_ehsr.  vlewcut.  qusrycut,  elap_tl«s.  tbl_cnt. 
run  rslt) : 


) 

void  module  sm(char  cntrl_ch4r.  Int  vlewcut.  long  querycut.  double  •tlaesn, 
riLE  ‘run  relt) 


< 

clock_t  tstart  •  0,  tstop  •  0: 
double  elap_tlme; 
long  tbl_cnt  •  0; 
exec  eql  begin  declere  section; 
Int  vlew_cut: 
long  query_cut: 
long  snua; 
char  snaM[211; 
long  skayno; 

exec  sql  and  declare  section; 
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«xec  sqX  d«clar«  %m_cl  cursor  for 
selsct  e_nua.  enaoe.  keyno 
from  sm_view 

where  salary  >•  :query_^cut: 
view  cut  *  viewcut: 
query_cut  *  querycut: 
swi tch ( cnt rl^char ) 

{ 

case  ' K* : 

create_update_table ( ) : 
exec  sql  Insert  into  possa 
select  * 
froa  update^tbl: 
tstart  «  clock( ) : 
exec  aql  Insert  into  pos_pria 
select  e_nuB.  keyno 
froa  update  tbl 
where  level  >•  :view^cut: 
tstop  a  clockO: 
exec  sql  drop  update^tbl: 
break: 
ease  'Q*: 

tstart  a  clockO: 
exec  sql  open  sa^cl; 

exec  sql  %rhenever  not  found  qoto  closeaa_cl: 
while  (sqlca-sqlcode  ■■  0) 

( 

exec  sql  fetch  sa^cl 

Into  :snua,  :snaae.  tskeyno: 

/*  printf  CNnsnua  •  Xd" .  snua) :  •/ 
tbi_cnt**; 

} 

closesa^cl: 

exec  sql  whenever  not  found  continue: 
tstop  a  clockO: 
exec  sql  close  sa^cl; 
break: 


89 


default: 


prlnt£(’‘\Nincorrect  control  character\n"  ) : 
break: 


} 

elap_titne  *  (tstop  -  tatart )/ (double) CLK_TCK: 

*timeaa  «  ^timeam  elap^^tine: 

write  run  reault(a’.  cntrl^char.  view^ at.  querycut.  elap 
run  ralt ) : 


} 

void  oodule_£m(char  cntrl_char.  int  vlewcut.  long  querycut. 
FILE  •run^rslt) 

( 

clock_t  tatart  -  0.  tatop  *  0: 
double  elap^tiae: 
long  qcnt  ■  0: 

eaec  aql  begin  declare  aection: 
int  view^cut: 
long  query^cut: 
long  tbl^cnt: 
long  fnua: 
char  fnaaeC211: 
long  fkayno: 

eaec  aql  end  declare  aection; 
eaec  aql  declare  foi^cl  curaor  for 
aelect  annual,  enaaa.  keyno 
froB  full^Bat 

where  salary  >•  ; query ^cut: 
view^cut  •  vlewcut; 
query ^cut  •  querycut: 
awitch(cntrl_char) 

{ 


time,  tbl  cnc. 


double  *tiBefB. 
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case  ’ K*  : 


create_up<iate_tabl«( ) : 
exec  aql  insert  into  posfffl 
select  * 


from  update^tbl; 
tstart  •  clock( ) : 

«MS  i<al  dfflB.fuXijit; 

«»«c  «gl  cr««t«  t«bl«  full_m«t 

_ le  nua  int«aT2.  tname  g20.  ««l«rv  lntea«r< 

•xmc  «al  ln««rt  into  full_ajt  (»_nua.  aname.  « 
«el«et  enpfm.e  nuM.  ampfn.enMie.  eaDfn.«i 
from  «BPfn.  potfia  oufr 


_ whT«  «aDfa.« jiua  ■  inner .e  nun 

— and  outar.kavno  ■  InnT.keyno 
_ and  Innar.lavl  >.  :Tl«w_eutl- 

_ tMC  lal  MdlfT  fuiijdt  ta  cbtrct  an  Mltni 

tstop  >  clock(); 
aaac  aql  drop  updato_tbl: 
braak; 
caaa  'Q' : 

tatart  •  clockO; 
aaac  aql  opan  fa_cl: 

aaac  aql  whanavar  not  found  goto  cloaafa_cl; 
whlla  ( aqlca. aqlcoda  «•  0) 

( 

aaac  aql  fatch  fa_cl 

Into  ;fnua,  :fnaM.  ifkayno; 

/•  prlntf("\n  fnuai  •  *d".  fnua);  */ 
qcnt**: 

) 

cloaafa_cl: 

aaac  aql  whanavar  not  found  contlnua: 
tatop  •  clockO; 
aaac  aql  cloaa  fa_el; 
braak; 
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default : 


printf ("\Nincorrect  control  characterNn" ) ; 
break: 

y 

elap_titne  »  (tatop  -  tstart )/ (double) CLK_TCK: 

•timefm  «  *tioefm  ♦  elap^time: 
exec  eql  select  rowtot  ■  count(e_nun) 
into  :tbl_cnt 
froa  full^nat 

where  salary  >■  :query_cut: 

write^run^reault( '  f  ’  .  cntrl__char.  vlewcut.  querycut.  elap_tlne,  tbl__cnt. 
run  rslt) : 


> 

void  wrlte_f ile_headlnga(char*  paraa.  char*  updt^tbl,  FILE*  fresult  fl. 
FILE*  run  rslt) 


{ 


tl®e_t  today^t; 
tiae(6today_t) : 

fprlntf (fresult_fl. "Nn  %•  -  FINAL  RESULTS  (vagxpdp?)  -\n" .  ctlme(6today_t) ) : 
fprlntf  (fresult^fl.  "Xn  The  Rs  is  the  parameter  being  tested**,  paraa) : 
fprintf  (fr«sult_f  1.  "Xn  The  %%  table  is  the  table  being  updated*'.  updt_tbl) ; 
fprintf  (run_rslt.*'Xn  Ks  -  RUN  RESULTS  (vegxpdp?)  -Xn**.  ctiae(&today_t) )  ; 
fprintf (run^rslt.'*Xn  The  %m  is  the  parameter  being  tested**,  param); 
fprintf (run^rslt. "Xn  The  %s  table  is  the  table  being  updatedXn".  updt_tbl) ; 

> 

void  write_run_result(char  strat.  char  cntrl^char.  int  vlewcut.  long  querycut, 
double  elap^time,  long  tbl_cnt.  FILE  *nin_rslt) 

( 

printf ("XnAcm  ee"%c  vc*gd  qc«Sld  et»1(.21f  tc*%ld".  strat.  cntrl^char. 

vieweut,  querycut.  elap_tiM.  tbl^cnt): 
fprintf (run_ralt, "XnSem  cc«%c  vc-td  qc«Eld  et«E.21f  cc«»ld". strat, 
cntrl^char,  viewcut,  querycut,  elap_tlae,  tbl_cnt); 

> 


a 
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void  wrtt«_f lnal_re»ult ( int  run.  Int  viewcut.  long  guerycut.  int  updt_»iz. 

long  countb,  long  councv.  long  countq.  float  fv, 
float  fva,  float  fq.  float  fqa.  float  P, 
double  tltneqm.  double  tltnestn.  double  tlmeftn. 

FILE  ♦freault_fl.  FILE  •run_rslt) 

< 

printf ("XnXnRUN#  »d,  VCUT*  *d.  QCUT»  *ld,  «TUP-  %d.  BASE*  *ld,  VIEW-  «ld,"\ 

"  QUERY-  %ld" .  run.  viewcut.  querycut.  updt^air.  countb.  countv. 
countq) : 

prlntf CNnFV-  *.2f.  FVA-  %t .  FQ-  ».2f,  FQA-  »f  P-  ».2f",fv.  fva.  fq. 
fqa.  P); 

prlntf ("NnTIMEQM-  ».31f  aec.  TIMESM-  ».31f  aec.  TIMEFM-  ».31f  aec\n" . 
tlmaqm,  tlneam.  tiaiefm) ; 

fprlntf (freeult_fl."\n\NRUN«  »d.  VCUT-  «d,  QCUT-  »ld.  #TUP-  «d.  BASE-  «ld."\ 
'■  VIEW-  Eld,  QUERY-  Eld",  run,  viewcut.  querycut,  updt_si<.  countb. 
countv.  countq): 

fprlntf (freault_fl."\NFV-  E.2f,  FVA-  Ef.  FQ-  E.2f.  FQA-  Ef  P-  E.2f-,fv.  fva. 
fq.  fqa.  P): 

fprlntf (freault_fl,"\NTIMEQM-  E.31f  aec.  TIMESM-  E.31f  aec.  TIMEFM-  E.3If"\ 

''  tac\n" .  tlmeqa.  tlmeam.  tlmefn) ; 

fprlntf (run_ralt."\n\MRUN#  Ed.  VCUT-  Ed.  QCUT-  Eld.  »TUP-  Ed.  BASE-  Eld,"\ 

"  VIEW-  Eld.  QUERY-  Eld",  run.  viewcut,  querycut,  updt_sl>.  countb, 
countv.  countq); 

fprlntf (run_ralt."\NFV-  E.2f.  FVA-  Ef,  FQ-  E.2f.  FQA-  Ef  P-  E.2f“.  fv,  fva, 
fq.  fqa,  P): 

fprlntf (run_ralt."\NTlMEQM-  E.3lf  aec,  TIMESM-  E.31f  aec.  TIMEFM-  E.31f"\ 

"  secNn" . tlaeqe.  tlaeee.  tlaofa) ; 

> 

void  coapute  avg  tlaednt  Q,  double  *tlaeqa.  double  vtlaeaa.  double  *tlBcfB) 

< 

lf(Q  >  0) 

( 

Ftlaeqa  -  *tlaaqB  /  (doubla)Q; 

Ptlaeaa  -  *tlaosa  /  (double)Q; 

*tlaefa  -  *tlaefB  /  (doubla)O: 

) 
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•Is* 

( 

printf CAnVNERROR:  dividing  times  by  0.  **•*  results  ere  VOID  ••••\n'); 

} 

void  compute_fv_and_fq_and_P(int  vmax.  Int  vbase.  int  vincr.  int  vcut, 

float  Pfv.long  qmaz.  long  qbase.  long  qincr. 
long  qcut.  float  “fq.  Int  K.  int  0.  float  •?) 

( 

•fv  •  (float)  (visas)  -  ( (float)  (vcut  -  vbaae)  /  (float)  (vincr) ) : 

•fv  •  (*fv  ♦  (float) (vincr)  /  (float) (vincr) )  /  (f loat) (vaas) : 

•fq  •  (float)  (qisas)  -  ( (float)  (qcut  -  qbase)  /  (float)  (qincr) ) : 

•fq  •  (“fq  ♦  (float) (qincr)  /  ( float ) (qincr) )  /  (float) (qmas) : 

*p  -  (float) (K)/(float) (K  ♦  0): 

) 

void  coBputa_tabla_counts(long  ‘countb,  long  •countv,  long  ‘countg. 

long  quarycut.  float  ‘fea,  floe-  ‘fqa) 

( 

•sac  sql  begin  declare  section; 
long  querT_cut; 
long  tbl_cnt: 

esee  sql  end  declare  section: 

querT_cut  •  quarycut: 

asec  sql  create  table  baa*_eat 

(e  nu«  IntegarZ.  anaae  c20.  salary  integerd,  )ieyno  Inte9*r2): 
•sec  sql  insert  into  baae_aat  (•_nuB.  enaae.  salary,  keyno) 

select  •■pfB.e_nua.  eapfs-enaae.  empf a. salary,  posfB.)t«yno 

froa  eapfa.  posfa 

where  eapfa. e^nua  •  posfa. •_nua: 

•sec  sql  select  rowtot  •  count(e_nua) 
into  :tbl_cnt 
froa  base^aat; 

•countb  •  tbl^^cnt: 

•xsc  sql  select  rowtot  •  count (•_nua) 
into  :tbl_cnt 
froa  full_aat: 

•countv  •  tbl^cnt: 


I 


I 


e 


e 
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cxcc  aql  •elect  rowtot  »  count (e_num) 
into  : tbl_cnt 
from  full__ii»et 

where  •elery  >■  tquery^cut: 

•countq  «  tbl  ent: 

*<v«  *  ( float )(( double ) *countv  /  ( double ) *countb ) : 

•fqe  »  ( float )( (double) *countq  /  { double )*coun tv ) : 
exec  aql  drop  baee^nat: 

) 

void  ref reeh_update_text_f lie ( long  card,  long  i.  long  update^ait) 

( 

long  update_baae; 

int  nun_of_f ielda.  change^field  •  4: 

char  flle_naae(elie]  •  updatinfo.  *flle_ptr: 

FILE  •updat_fl: 

atruct  field_attrib 

{ 

char  fleld_type: 

Int  field_width: 
char  fleld^info: 
long  lower^bound: 
int  increaent: 

I'^ng  upper  bound: 

■truct  fleld_attrlb  *next: 

): 

•truct  field_attrlb  •flr«t_fleld  ■  HULL: 

■truct  fleld^attrlb  *current_f ield  ■  NULL; 

•truct  fleld_attrlb  *print^ptr  •  HULL; 
file^ptr  •  Afiie__naa«[0] ; 

update^baa*  ■  (1  *  updata^alt)  *  card  /*  coaputa  new  Key  base  number  */ 
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/••  Read  old  control  input  for  data  generation  program  *•/ 
updat_fl  •  fopen(update_fila.  "r'l: 
if ( : updat_f 1 ) 

( 

printf (  AKERROR:  update  control  file  did  not  open  to  read"): 

fcloaeal 1 ( ) : 

exec  aql  disconnect: 

exlt(l) : 

> 

facanf(updat  fl.  "**d\n'); 

V 

f  scant  (updat_fl .  "M\n“.  fcnus_of_iields) : 

f scant (updat_fl .  "\*s\n"):  ^ 

for  (J  •  1:  J  <•  nu*_of_f lelds;  J»*) 

( 

if  (J  ••  1) 

< 

firat_flsld  •  (struct  flsld_attrib*)aalloc(slisof (struct  f lsld_attrlb) ) ; 
if  (first_flsld  ••  miLL)  printf eXMERROR:  Mssory  did  not  allocsts! ! ! " ) : 
currsnt_f laid  •  flrst_flsld: 

) 

alas 

( 

currant_f laid- >naHt  '(struct  flald_attrib*)aalloc(slxaof (struct  f iald_attrlb) ) ; 
currant_f laid  •  currant_flald->nast: 

) 

currant_f laid- >naBt  •  NULL: 

fscanf (updat_fl.  "XnRcNn".  *currant_f lald->f lald_tTpa) ; 
f  scant  (updat_fl .  "MNn".  *currant_f  lald->f  lald_wldth) ; 
fscanf (updat_tl.  "beXn",  *currant_flald->flald_tnfo) : 

fscanf  (updat_fl,  “*ld\n".  *currant_f lald-Howar^bound) :  * 

fscanf  (updat_fl.  "MNn".  *currant_flald->tncraaant) ; 

< 

fscanf  (updat_fl.  "Wdyn",  4currant_f lald->uppar_bound) ; 

If  (J  ••  ehanga  flald)  /*  changing  basa  for  kayno  flald  */ 

( 

currsnt_flald->lowar_bound  ■  updata_basa: 

) 

) 

fcloBa(updat_f 1) : 
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**  vrlt«  updated  control  Input  for  datA  generation  program  **/ 


updat^fl  ■  fopen(update_flle.  ‘w  '  I ; 
if  l  *.  updat__f  I ) 

I 

print  f  (■' 'NCRROR :  update  control  file  did  not  open  to  write"); 

fcloseal 1 ( ) ; 

exec  aql  disconnect: 

exlt(I)  : 

) 

fprintf (updat_fl.  ’tldSn'*.  update^sit): 
fprlntf (updat^f  1 .  "MXn*.  num^of^fields); 
fprlntf (updat_fl.  ”»s’*,  flle_ptrl: 
prlnt^ptr  ■  flrst_field: 
whlle(prlnt_ptr  :■  MULL) 

I 

fprlntf  (updat^fi .  ''VnXntcXn",  prlnt^per'»>field_tfpe) ; 
fprlntf (updat_fl .  "tdXn".  prlnt^ptr- > f ield^width) : 
fprlntf  (updat_fl.  "^cNn** .  prlnt_ptr->f  leld^lnfo) : 
fprlntf  (updat^f  I .  "tldXn** .  prlnt_ptr*>lower^bound) : 
fprlntf (updat^fl .  *9d\n" .  prlnt_ptr«>incre«ent) : 
fprlntf (updat_fl .  "tld" .  prlnt_ptr->upper^6ound) : 
prlnt^ptr  ■  prlnt^ptr->next: 

} 

fclos«(updat^fl ) ; 
syatM(  "datagen'* ) : 

\ 
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